I’m heading home with my brain stuffed full of new knowledge from Droidcon London 2010. And this was just the first day, with unplanned, unprepared barcamp-style presentations!
Most of the presentations today were technical (tomorrow there’s a design and business thread as well) but they varied from doing continuous integration through discussing low-level TCP details to a Q&A session with some of Google’s Android team.
I’m seriously looking forward to the second day’s programme.
In the meantime, here’s my notes for the sessions I attended:
Android UI tricks from Sony Ericsson
- limit of 200ms to respond to user interactions — don’t do long running tasks in the UI thread
- so how do you deal with longer lasting processes? use the Handler & Service classes
- …and use Toasts to show quick popup status
- number of devices on 1.5 is below 10%
- all demos will be available on the Sony Ericsson developer blog
Handler
- don’t use inner class Runnables inside a Handler (save heap & garbage collector)
- within XML use onClick for buttons
handler.sendEmptyMessageDelayed(message, delay);
- then have a message handler that deals with loop & sends next message
- any UI activity should be in a Runnable called with
runOnUiThread(runnable)
- any UI activity should be in a Runnable called with
- don’t forget onDestroy
Service
- used for downloading
- pass a message from service to activity by implementing your own Application class
- Application defines callback interface and methods to fire & receive
- use
IntentService
for your service- deals with sequential handling automatically
- call to the application (need to cast
getApplication()
) - don’t use AIDL interfaces — unless you want to share service with other apps or between multiple processes in your app
Animation
- create an AnimationSet and add Animations within the
getAnimation
call - second parameters for
RotateAnimation
are relative to view, not screen - can also do animations in layout.xml
- Twitter app removed animations from their home screen…
- the background was a live wallpaper — consumes a lot of battery
- continuous animations can use up battery so be careful
- shouldn’t be a problem with performance though
- see also Zooming demo and
BootListener
- when the phone is rebooted, the alarms are cleared
- don’t listen for boot completed unless you really have to
- slows down startup if you have too many
- can have a broadcast receiver that is disabled
- in app xml set bootlistener disabled by default
- then in listener when intent comes through: {{{ context.getPackageManager().setComponentEnabledSetting( new(ComponentName(context, BootListener.class), PackageManger.COMPONENT_ENABLED_STATE_DISABLED, PackageManager.DONT_KILL_APP) }}}
3D & OpenGL with Android views
- combine the strengths of Android views (text, layout, etc) with OpenGL (3D but not text)
- create a bitmap
- use MeasureSpec method
- draw the view onto the OpenGL texture bitmap
GLUtils.texImage2D(...)
- if you do this today, suggest you use OpenGL ES 2.0
Location services
led by Nick Black, Founder & Head of Products at Cloudmade
cloudmade
- cloudmade will support Android later this year with a Maps SDK
- based on OpenStreetMaps
- worked out a way to squeeze vector data onto the device
- map data comes as you need it and is stored locally on device
- downloadable data includes searchable street names, etc
- early access available end of this year, early next year
- cloudmade also has http://maps.cloudmade.com/editor to let you choose and configure your design —- your style will work on mobile too!
Impleo
- formed from ex-Motorola & Alcatel employees
- also adding tracking for insurance
- includes accelerometer info so can tell how good a driver you are!
cloudmade location-based advertising
- created a network that finds highest value ads from other networks
- goes out to other ad networks, will also go out to more specialist networks
- trying to deal with the fill-rate problem…
- some android apps got backlash when adding advertising after the app release
- put the ads in at the beginning!
map data
- most owned by Google, Nokia or Tomtom (Navteq)
- skobbler Android app - built on cloudmade’s navigation service
- cloudmade see navigation services not as an app but as a feature within apps
- Google don’t allow access to driving directions API on Android
google latitude and other services
- Is anyone using the latitude API?
- GPS in Android drains the battery quite heavily
- if things are further away then turn off GPS temporarily
- battery management isn’t good built-in
- have to manage your own choice between coarse and fine location services
- Motorola went to use Skyhook instead of Google location API on Android
- that way they would get data for their customers WiFi location
- Google forced them to switch back to Google location
- Skyhook now suing Google…
Always in sync client & local unit testing
Carl from Novoda (@charroch)[http://twitter.com/charroch]
RESTProvider
- available on github
- depends on JacksonJSON etc
- makes a RESTful API available as a Content Provider
- couple of branches — caching_carl one stores locally in SQLite
- can start service with loads of requests — it will handle them in a queue
- can add params:
putExtra("params", new List
(...)) - Tip:
adb shell setprop log.tag.Database VERBOSE
- slows it down a lot
- can add your own tags too
- ResultReceiver: a way of passing back status to app UI
- if connectivity is lost, it stops the queue
- need to watch out for the user setting to disable background downloading
- extend HttpQueuedService
- override getMarshaller
- create a LoggableJsonRequest with a marshall method to store data using a ContentProviderOperation
- library supports ETags too — saves a download as server data is just a HEAD response
- also created novoda.mixml (minimal XML) which works in same way as Jackson JSON
- integrated into RestProvider to cope with XML content as well as JSON
- hopefully have time to build a more stable version over the new year
- end goal: to have declarations in application XML and service definition
Unit testing of android classes without emulator
- see also the RestProvider code on github
- android.jar only contains stubs, so can’t even instantiate
- major problem for your subclasses even when you only want to test your additional methods
- PowerMock works somewhat
- need to find a different way of doing the tests
- Carl has copied the source of the Android classes into his test source and modified them to ensure no call to the system…
- not too hard — just need to ensure that the constructor can work
- have to keep your code copy up to date with the base Android source
- but it doesn’t matter that much as you won’t be testing Android code
- possible next step: Android will run on Intel — could run locally with unit tests
- currently have three projects:
- main classes
- local tests using this mechanism
- instrumentation tests
- changing to have a single folder with tests marked with annotations
- want to have some tests marked as local if possible
- android instrumentation tests should run all of tests (including local tests)
- maven could be overkill for Android development
- build process is quite well-defined, not that many other libs
- SBT could be interesting (simple build tool, written in Scala)
App Analytics from Capptain
- combining in-app analytics with CRM
- collect/measure -> analysis -> engage
- send messages to users and get feedback
- SDK available in Android and iOS
- similar services: motally (acquired by Nokia) & xtify
- released beta two days ago
- have REST/JSON API for data
- not publicly available right now, but available on a case-by-case basis
also have a real-time API
pricing:
- free during beta period
- haven’t decided pricing structure
- probably freemium — pay for additional functions/users
new analytics capabilities
- how long users are spending in each screen of your app
- really nice user path — based on screens, not events
- real-time analytics — can monitor where people are in your app right now
- crash logs with device, firmware, etc details
- as per other analytics, store data locally and send later if not connected
- Android SDK automatically picks up activities
CRM
- announcements and polls
- target by carrier, country
- test before publish by sending to a single device
- schedule for particular times
Qualcomm Alljoyn
http://developer.qualcomm.com/dev/alljoyn-p2p
- exposes a shared communication bus based on DBus
- automatically uses Wi-Fi and Bluetooth as device allows
- Java and C interfaces
- Java interface lets you just send/receive/call POJOs
- Wi-Fi uses mDNS to find services by well known name (a URI)
Continuous Integration with Maven & Hudson
Hugo Josefson from Jayway (founded Maven Android plugin)
http://code.google.com/p/maven-android-plugin/
Slides and Hudson installation script available from http://code.google.com/p/maven-android-plugin/wiki/Presentations
Android and Maven
- there’s also a proguard plugin — can use to trim unused classes
- maven can handle inter-project dependencies
- keep pure Java code in a Library (so can have local unit tests)
- then can have app depend on library and on-device tests depend on app
- see Samples project for MorseFlash example
- there’s also an Eclipse plugin that helps ADT & Eclipse understand that they’re dealing with Maven
- the process that takes the longest time is the DEXing
Android, Maven and Hudson
- don’t see any reason to run Hudson in Tomcat — it comes with its own webserver
- though it should work fine within Tomcat too
- Android emulator plugin for Hudson: http://wiki.hudson-ci.org/display/HUDSON/Android+Emulator+Plugin
- emulator settings:
2.2, mdpi, hvga, en_US, 64M
- can loop through different settings for emulator
- Hudson server needs some X libraries but will still run headless
- currently don’t find out which tests fail when Android tests fail — have to look at logs
Google Q & A
I only noted down one question from the second Google Bootcamp Q & A session:
- can you target apps at Android tablets?
- can target large screen devices (currently Galaxy Tab + Dell Streak)
- will also hit Evo 4G as that has hi resolution too, but smaller screen