September 1st, 2010
A great many of the applications I create, run in the background and periodically send or receive information from a server. The Sony Ericsson Developer blog has just published an interesting post today on ‘Reducing power consumption of connected apps’. While the post talks about and provide examples for Android, the techniques can also be applied to some other platforms.
In summary, they are…
- Synchronize your polls with other apps
- Make polls short
- Manage your connections
- Stop your services
Now that network operators are starting to drop
‘unlimited
‘ tariffs, it’s not just power consumption but also data consumption that is becoming critical for users. An app communicating several times an hour can quickly rack up significant data use.
Here are some corresponding tips on reducing data usage…
- Optimise your data design to do multiple requests for data in one transaction with the server
- If using HTTP then use HTTP compression
- Allow the user to view how much data has been used and allow them to change polling periods
- Have the server know when the phone was last updated and only send what’s charged rather than ‘everything’
- Avoid XML based web services and use simple HTTP GET, POST and JSON
- Think about using TCP rather than HTTP
- Don’t use SSL unless you really have to (does it really have to be that secure?)
- Where possible, use server initiated notification systems rather than polling
Thinking more about data use and polling will also provide large server scalability gains that you will appreciate once you start getting larger numbers of users.
Related Articles:
Posted in Mobile
August 31st, 2010
MonoDroid is a new way to develop Android applications using c# and .NET. It’s based on Mono, the open source development platform based on the .NET framework, that’s itself is sponsored by Novell.
The idea is that you use a Visual Studio 2010 plugin to develop Android applications against the API profile for the MonoTouch core libraries (the Silverlight-based API).
This set me thinking why you might (or might not) want to do this instead of programming using Android’s Java.
Advantages
- It allows developers with c# expertise to develop Android applications.
- It allows both Windows Phone 7 and Android to share some common code (note it’s not possible to have a WP7 app instantly run on Android. The APIs differ and common code, usually business logic, has to be factored out so it can be shared).
- Visual Studio is, in my opinion, the best available tool for mobile software development.
Disadvantages
- You become dependent on a on 3rd party tool that won’t have a complete API nor evolve as fast as the Android API itself.
- It won’t work with Visual Studio 2010 Express (the free version) as it doesn’t support plugins. Visual Studio 2010 Professional or better is required.
- There’s no UI designer (one of the main strengths of using Visual Studio).
- It costs - probably in the same range as MonoTouch ($400 USD for individual users, and $1,000 for enterprise users).
Related Articles:
Posted in Mobile
August 26th, 2010
Research2Guidance has some research that shows the smartphone application market reached more than 2.2. billion dollars in the first half of 2010. For comparison, this half year figure is more than that for the whole of last year (2009).
We are told…
"the overall decline of app prices has reclined" and
"Average application prices steeped to $3.60 US per paid application in the first half of 2010"
Research2Guidance predict that "The next wave of new app stores will be niche stores specializing on e.g. business or mobile health apps."
While I believe there’s a lot of potential in more vertical apps, I suspect they will be sold B2B rather than via niche stores.
Related Articles:
Posted in Mobile
August 25th, 2010
James Gosling (the original designer of Java) has an interesting post on comments to his previous blog entry about Google, Oracle and Java.
When asked why Android works well across many phones while Java ME didn’t, he says that…
"Today’s high end phones have an incredible amount of RAM and CPU, which makes interoperability hugely easier for Android."
and
"Differences will creep in as the Android world ages: version skews, different bug fixes, and the handset makers attraction to ‘added value’ and ‘product differentiation’ will all take their toll without strict governance"
While I agree and have previously written about difference creep, I am not sure how more powerful phones necessarily make phones more interoperable.
I worked at Symbian for a year, on the Symbian Java VM, towards the end of it’s life and these are the things that I think are the main contributors to Java ME fragmentation…
- Differences in hardware. Almost all smartphones (not just Android phones) have converged on a very similar high specification. I’d say this similarity of phones has aided Android interoperability as opposed to them necessarily being powerful.
- Differences in JVM implementation. Different Java ME phones use a variety of JVMs that have interpreted the JSRs (specifications) in different ways. Android has one JVM so there are no differences across phones for a given JVM version.
- Bugs in JVM implementations. Again, the variety of Java ME JVMs implementing the same specification allows different ones to exhibit different bugs.
- Differences between successive versions of JVMs. Java ME and Android both suffer from this but Android less so because some phones can be upgraded to later OS (and JVM) versions.
- Additions to the official SDK APIs. This is part of the difference creep ("added value" and "product differentiation") James refers to. On any platform, additional APIs tend to be ignored by the majority of developers as they restrict the market for an application. Very few apps need or use these APIs. There’s a disincentive to use them.
Related Articles:
Posted in Mobile, J2ME, Android
August 24th, 2010
Mobile Entertainment has a great new presentation at SlideShare on 157 App Stats You Should Know About. It brings together mobile statistics from many sources and also provides lots of success cases.
While mentioning success cases, you might also like to take a look at
Arron La’s Advanced Task Manager Android Revenue. Arron’s experiences are contrary to mine and I suspect much of his success was due to his application being listed by Google as a top application.
Posted in Mobile
August 20th, 2010
If you are in any way interested in mobile then you should take a look at Ericsson Labs links on Delicious. They have over 1000 mobile related links that I believe are an archive of what they have posted on Twitter. I have found Ericsson Labs on Twitter to be one of the best sources for new mobile news.
While mentioning Ericsson Labs, I should mention they have many interesting and innovative APIs you can experiment with in your own apps. Their motivation for providing these APIs is to eventually move the more popular ones over to Ericsson IPX.
Posted in Mobile
August 19th, 2010
As an independent developer working of different types of projects over time, I am sometimes the first to experience changes in the type of mobile development being undertaken. For example, last year, I saw and reported on the rise of brandware and marketing agencies commissioning applications.
At the moment I am seeing an unexpected increase in interest in Symbian development. This is interest in native Symbian development rather than Qt. I say ‘unexpected’ because new Symbian development has, from my viewpoint, been dead and dying for many months now. So what’s causing the new interest in Symbian?
Many new Symbian projects are coming from companies that have already implemented on iPhone or BlackBerry and are looking to diversify their platforms. Symbian (mainly Nokia) still has large sales volumes and with the forthcoming Nokia N8, I guess companies are starting to hedge their bets.
Related Articles:
Posted in Symbian, Series 60, Mobile
