Sixth edition of droidconIN.
droidconIN is part of the world wide series of conferences that happens in London, Paris, Berlin, Netherlands, Tunis, Ankara and Brussels. The first edition of droidconIN was at Bangalore in Nov 2011. The second edition in Nov 2012 was featuring General & Specialized Topics, Native + HTML5 and App Demos. The 2013 edition was about Systems, UX, Gaming, Business and App Demos. The 2014 edition featured dedicated tracks for deep dives into UI/UX, Data sync & versioning, App Demos and hardware. The 2015 edition had advanced technical talks with an emphasis on developing for resource contraint regions like India.
This edition spans two days of talks. We are inviting talk proposals for:
- Full-length 40 minute talks.
- Crisp 15 minute talks.
- Sponsored sessions, 40 minute and 15 minute durations (limited slots available; subject to editorial scrutiny and approval).
- Hands-on Workshop sessions, 3 and 6 hour duration.
Proposals will be filtered and shortlisted by an editorial panel. We urge you to add links to videos / slide decks when submitting proposals. This will help us understand your past speaking experience. Blurbs or blog posts covering the relevance of a particular problem statement and how it is tackled will help the editorial panel better judge your proposals.
Selection process is stringent and we follow the procedure outlined in this flowchart:
A talk is NOT confirmed till speakers recieve explicit communication from us saying that it is.
A talk can be rejected at any stage by us if we feel the speaker will not fit in the conference for the year. A talk can be canceled by the speaker at any time for any reason. (We would appreciate it, of course, if it isn’t at the last moment.) Please note that selected speakers must mandatorily participate in two rounds of rehearsals before the conference. This not only helps us adhere to the HasGeek format and quality, but also helps speakers prepare better for the intended audience.
There is only one speaker per session. Entry is free for those who are selected. Due to budgetary constraints, we prefer speakers closer to home. But if we think you stand out, we’ll provide a grant to cover part of your travel and accommodation to Bangalore. Grants are limited and are made available to speakers delivering full sessions (40 minutes or longer) only.
Updated (6th September, 2016): We are currently looking for talks in the following topics:
- Toolchains - What’s the latest in developer toolkits to help with build systems (Gradle, Buck, etc), speeding up the dev feedback loop, etc.
- Kotlin - An experienced speaker to help breakdown what Kotlin is, why and who should use it.
- Firebase - A case study of Firebase in an medium/large app, with insights on it’s benefits, drawbacks, and when/where it makes sense.
- Everything else - Anything else of relevance to an Android developer that we might have missed out.
Commitment to open source
HasGeek believes in open source as the binding force of our community. If you are describing a codebase for developers to work with, we’d like for it to be available under a permissive open source licence. If your software is commercially licensed or available under a combination of commercial and restrictive open source licences (such as the various forms of the GPL), please consider picking up a sponsorship. We recognise that there are valid reasons for commercial licensing, but ask that you support us in return for giving you an audience. Your session will be marked on the schedule as a sponsored session.
For more information about speaking proposals, tickets, and sponsorships, contact firstname.lastname@example.org or call +91-7676332020.
Deadline for submitting proposals:
- Proposal submission deadline(updated): 19 September 2016
- Schedule announcement: 10 October 2016
- Conference dates: 10 and 11 November 2016
We expect you to submit an outline of your proposed talk – either in the form of a mind map, a text document or draft slides along with your submission. You can edit your submission at any time.
Proposal submissions are now closed.
Continuous Delivery Pipeline for Mobile Applications
Why we needed it
“An engineer in an internet company should be able to think of ideas, build prototypes, translate feature specs (or discussions) into workable components, design architecture, write good code, test what has been built (ideally TDD), review code, monitor servers, scale applications, analyze logs, plan capacity, design databases, implement and use caching efficiently, tweak web servers, tweak databases, build fast, release faster, learn new tech to ride new waves etc .” Vibhore Sharma, our CTO, blogged this in 2011. Half a decade has passed but this is still very true and I think will be so even couple of decades down the line.
This talk presents how one can design and benefit from continuous delivery systems for Android apps.
Very often in mobile apps, we see that builds are generated by developers on their local machines which are then sent out to testers or to play store. This is quite risky and error prone esp. when working in larger teams. An app like ours uses a couple of third party sdk that can have different versions floating. The standard steps for building an app such as clean, compile, release, install etc… have been automated on a scheduled or triggered basis. It has empowered product owners to pull a fresh stable build any time they want to.
As the rule says, whatever can be unit tested should be unit tested. Besides functional tests, we also write unit and integration tests. In order to get the full benefit of unit tests, the test suite is run as part of build process daily. Developers may accidentally check in code that does not work, so we test early and often, to ensure that the code committed into repository is healthy.
After the test cases pass, static code analyzers like Lint are run to check the code quality and potentially mark the build as unstable or fail if some errors were introduced in the latest commit.
BVT (Build Verification Testing)
We also have Build Verification tests in place which run on every new build. It verifies that build is testable before it is released to test team for further testing. These test cases are core functionality test cases that ensure application is stable and can be tested thoroughly.
The functional tests are executed daily on our production and test environments. These tests are managed using TestLink tool, scheduled using Jenkins and executed using Appium.
After the execution of test cases, code coverage reports are generated using JaCoCo and Slather. All teams have been given a minimum code coverage target. As a next step we will fail a build if anytime the code coverage falls below a defined threshold value. Coverage trends will be published to all at the end of each iteration.
If the build is passes all the above mentioned steps, then it is marked as success and distributed via email to QA team/ product owners to do final testing.
Automated Build, Test and Release Process
When software development processes are automated, they are repeatable, reliable and can be run frequently. By automating the build and test processes we not only have saved time, but have also enforced standards. It also gives developers an immediate feedback on their work.
-How a typical workflow looks like
-Why this approach is error prone
-How we did it
-Using Jenkins tool automating build processes, continuous integration and automated deployments
-Test results, coverage trends and code analysis reports
-step by step guide of how to integrated various tools for android apps
Sudeep has >5 years of extensive experience in design and development of Android Applications. He is expert in designing architecture styles like MVC, MVP, MVVM, Sudeep is passionate about implementing high performance, data driven, native android apps. Currently working as android Technical Lead.