tag:blogger.com,1999:blog-2845715844756139152024-03-13T02:47:54.214+01:00Perpetum Design BlogPerpetum Designhttp://www.blogger.com/profile/07044191639104974132noreply@blogger.comBlogger14125tag:blogger.com,1999:blog-284571584475613915.post-20802521697342525502014-09-25T17:16:00.001+02:002014-09-25T17:16:01.946+02:00Introducing Messages for AndroidWe are pleased to announce our latest application, Messages for Android. Messages allow you to see consolidated view of all your messages (both emails and SMS, with more message types possibly added in the future release), which comes handy if you have multiple e-mail accounts and you are tired of the necessity to switch among them in the GMail client.<br />
<br />
<h3>
Why another e-mail client ?</h3>
<br />
The main reason for us to create Messages is the fact that e-mail database is currently not accessible for third parties on Android through any API, while Google never gave any official comment to this omission, my guess is that they would cite security reasons for this decision, clearly you don't want to give access to your emails to some rogue application on your Android device. It goes along the lines of a popular request of <a href="https://code.google.com/p/android/issues/detail?id=6266">fine-grained access to Android permissions</a> which seems never be treated seriously by Android team despite it is highly demanded by the community for multiple years.<br />
To get around this limitation, we created Messages. You need to download it from the Google Play:<br />
<br />
<a href="https://play.google.com/store/apps/details?id=actiwerks.messages">https://play.google.com/store/apps/details?id=actiwerks.messages</a><br />
<br />
<i><b>Current status :</b> Please note that Messages Application is currently in beta, if you are interested to be a part of our tester community, please let us know.</i><br />
<br />
install it on your device, sign into any of your e-mail accounts (using standard IMAP/POP3 protocols/credentials) and your e-mails are accessible through Messages application, both from the UI and through API available for third party applications.<br />
<br />
We are very serious about the security of your data, and thus we designed a mechanism that protects your e-mails from being abused, yet is very simple to use by any application, as we don't want to limit the Messages to be used only in our own applications, such as <a href="https://play.google.com/store/apps/details?id=actiwerks.whoscalling">Who's Calling?</a>, it is open to anybody willing to implement the communication & security protocol.<br />
<br />
Here you find the description to the Messages API and how to use it.<br />
<br />
To access the messages provided by the Messages application, you need to use <a href="http://developer.android.com/guide/topics/providers/content-providers.html">ContentProvider</a>, which is standard way to access data from the remote application by the third party on Android. While Android provides a way to secure the access by third party as outlined <a href="http://developer.android.com/training/articles/security-tips.html">here</a>, it is bit to wide, can easily be overlooked when installing application (especially if such an application has a long list of permissions) and can't be revoked from within Messages. We came up with a different way to secure the access to the Messages ContentProvider.<br />
<br />
In order to access the provider you need to specify the following base URI :<br />
<br />
<span style="font-family: Courier New, Courier, monospace;">content://actiwerks.messages/</span><br />
<br />
In fact, this URI won't return any content. You need to append it with your own secure hash first :<br />
<br />
<span style="font-family: 'Courier New', Courier, monospace;">content://actiwerks.messages/your_secure_hash_here/</span><br />
<br />
Where you can get the secure hash from ? It is easy, just ask Messages application for one. This is done by sending it a request connect <a href="http://developer.android.com/reference/android/content/Intent.html">Intent</a> :<br />
<br />
<span style="font-family: Courier New, Courier, monospace;">actiwerks.messages.action.GRANT_ACCESS</span><br />
<span style="font-family: Courier New, Courier, monospace;"><br /></span>
Here is an example of the code that creates and sends such an intent :<br />
<br />
<span style="font-family: Courier New, Courier, monospace;">Intent intent = new Intent("actiwerks.messages.action.GRANT_ACCESS");</span><br />
<span style="font-family: Courier New, Courier, monospace;">intent.putExtra("appId", getActivity().getPackageName());</span><br />
<span style="font-family: Courier New, Courier, monospace;">startActivity(intent); </span><br />
<br />
The Messages application react to this request by displaying the dialog to the user, notifying that your application just asked for permission to access the data of the Messages application.<br />
<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiiUdwzcrBFqQ3zJndHo-SCyaydRfXkRkVZgXChCG5WheyZyZCYVY8sjulq_RgFFRZJxx4W8XgKinxbTg-G1e0EswHQ3TzHPVoeSJPeHj3AnDNbm_CASPypUDe-1_kA4uARojcvyjdHw48/s1600/GrantAccessInMessages.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiiUdwzcrBFqQ3zJndHo-SCyaydRfXkRkVZgXChCG5WheyZyZCYVY8sjulq_RgFFRZJxx4W8XgKinxbTg-G1e0EswHQ3TzHPVoeSJPeHj3AnDNbm_CASPypUDe-1_kA4uARojcvyjdHw48/s1600/GrantAccessInMessages.png" height="320" width="180" /></a></div>
<br />
<br />
Since the application needs to provide its package info that is both verified by the <a href="http://developer.android.com/reference/android/content/pm/PackageManager.html#getApplicationInfo(java.lang.String, int)">PackageManager</a> and used for the callback to your application, user knows which application is asking for access to data an can either grant or reject it. In case of granting the access privileges, they can be revoked at any time by accessing the dialog within the Messages application.<br />
<br />
Once the user does either grants or reject the request for the access to the ContentProvider data, the Messages application sends back another Intent carrying the information about result, and in case of the successful approval by the user, the data of the security hash for the application :<br />
<br />
<span style="font-family: Courier New, Courier, monospace;">actiwerks.messages.action.ACTION_ACCESS_RESULT</span><br />
<span style="font-family: Courier New, Courier, monospace;"><br /></span>
Your application should define a broadcast filter to be able to intercept and get the data from the reply Intent:<br />
<br />
<span style="font-family: Courier New, Courier, monospace;"><receiver</span><br />
<span style="font-family: Courier New, Courier, monospace;"> android:name=".receiver.MessagesAccessResultReceiver_"</span><br />
<span style="font-family: Courier New, Courier, monospace;"> android:exported="true" ></span><br />
<span style="font-family: Courier New, Courier, monospace;"> <intent-filter></span><br />
<span style="font-family: Courier New, Courier, monospace;"> <action android:name="actiwerks.messages.action.ACTION_ACCESS_RESULT" /></span><br />
<span style="font-family: Courier New, Courier, monospace;"> </intent-filter></span><br />
<span style="font-family: Courier New, Courier, monospace;"></receiver></span><br />
<br />
If the request to get access to was successful, the Intent contains extra String data with a key "hash". To get this data, do the following call :<br />
<br />
<span style="font-family: Courier New, Courier, monospace;">String returnedHash = intentFromMessages.getStringExtra("hash");</span><br />
<br />
If the returned value is non null, your access has been granted and you can use this hash in constructing the content provider URI and you will be able to get the data from the ContentProvider.<br />
<br />
Here is a diagram of the entire workflow :<br />
<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjyaRGONZLZFHEv2Na-ZpmIPQpJPQ-jIUFWvsdKzXxQxQYfsCI_Z096hytDIo3mfosDtKJdpVF_xwQ4jnSwy9oknveoau7ZhZWHoG_WymF5uMy2mcP5WBtxb8nlO21-3stIGF33EkWLTj0/s1600/CollaborationDiagram.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjyaRGONZLZFHEv2Na-ZpmIPQpJPQ-jIUFWvsdKzXxQxQYfsCI_Z096hytDIo3mfosDtKJdpVF_xwQ4jnSwy9oknveoau7ZhZWHoG_WymF5uMy2mcP5WBtxb8nlO21-3stIGF33EkWLTj0/s1600/CollaborationDiagram.png" height="138" width="320" /></a></div>
<br />
<br />
The description of the intents involved in this process are also available in the popular intent registry OpenIntents :<br />
<br />
<a href="http://www.openintents.org/en/node/953">http://www.openintents.org/en/node/953</a><br />
<br />
<h3>
Working with the content provider</h3>
<br />
Assuming you were able to get the correct hash to access messages data, here is the explanation of the commands you can get from the Messages content provider. Data are accessed using REST notation.<br />
<br />
<span style="font-family: 'Courier New', Courier, monospace;">content://actiwerks.messages/your_secure_hash_here/command/command_details</span><br />
<br />
The basic commands that can be used are :<br />
<br />
<span style="font-family: Courier New, Courier, monospace;">accounts</span><br />
<span style="font-family: Courier New, Courier, monospace;">mail/account_name</span><br />
<span style="font-family: Courier New, Courier, monospace;">sms</span><br />
<span style="font-family: Courier New, Courier, monospace;"><br /></span>
<span style="font-family: inherit;">First command will list the names of all available e-mail accounts that were added by the user to the Messages application. You can access any of the accounts by specifying that account name after the </span><span style="font-family: Courier New, Courier, monospace;">/mail</span><span style="font-family: inherit;"> part. Using </span><span style="font-family: Courier New, Courier, monospace;">/sms</span><span style="font-family: inherit;"> will provide the access to list of SMS as an e-mail pseudo-account.</span><br />
<span style="font-family: inherit;"><br /></span>
<span style="font-family: inherit;">For each account there might be more specific criteria included.</span><br />
<span style="font-family: inherit;"><br /></span>
<span style="font-family: Courier New, Courier, monospace;">in<br />out<br />read<br />unread<br />count</span><br />
<br />
<span style="font-family: inherit;">Using these subcommands will give you access to in-coming messages, </span>out-coming messages, already read messages, new (unread messages). If you specify <span style="font-family: Courier New, Courier, monospace;">/count</span> as the part of the URI, instead of the list of messages, the content provider will return a number, representing the count of the messages matching your criteria.<br />
<br />
If you add any other string except of these "reserved" commands it will try to search for user name containing this string (it can be in the recipient as well as "Carbon copy" a "Blind carbon copy" fields)<br />
<br />
Returned value from the content provider is a standard Cursor object, you can inspect its column dynamically to get idea of the data provided in each specific scenario.<br />
<br />
We will provide more information about dealing with the returned data from the Messages application in the followup post.<br />
<br />
<h3>
Conclusion</h3>
<br />
Hope you liked the outlined security framework over the standard Android Content Provider, we believe such revocable, "at the time of service usage" scenario, similar to what iOS users are familiar with offers significant advantages over the traditional Android permission based static system. Our solution is also a proof that there is no need for any special support from the Android OS to make a more granular, lifecycle controlled security solution happen, and we are definitely interested to hear your feedback.<br />
<br />
Please note that Messages Application is currently in beta, if you are interested to be a part of our tester community, please let us know.<br />
<br />Anonymoushttp://www.blogger.com/profile/13260257579662354666noreply@blogger.com0tag:blogger.com,1999:blog-284571584475613915.post-20411561261176655282013-06-15T09:38:00.001+02:002013-06-15T09:38:12.819+02:00Android Library as a .JAR file and accessing the resources in itThere was a new wave of discussions around possibility of packaging of the Android Library into a .JAR file and how to access resources in it. It is quite understandable, as current traditional solution, consisting of creating special Library Project and referencing such project from your main project, quite plainly, sucks. If you have multiple projects linked like this, your IDE will turn into crawling and you will constantly face breaks in this very fragile system.<br />
<br />
What are our options to solve this problem ?<br />
<br />
One possibility is to skip it altogether, and always copy all the files into the single project. It requires both discipline and good tracking system not to modify "library code" in two different projects, but it is manageable this way, and single flat project with no dependencies usually offers considerable speed advantages.<br />
<br />
But it is not always possible to use this, especially when you want to package your code into "Library" to be used by the third party. Google is well aware of this problem and in the latest iteration of its ADK (based on Idea and Gradle) plans to introduce a new system that would allow similar mechanism. But their choice to introduce yet another archive format (although it is very similar to .JAR, with just different manifest file) is puzzling, and there is no guarantee this would work for this particular purpose, given the long history of failures of the ADK team. Also there are cases, where .JAR is the only option. We were exactly in the same position as our <a href="http://www.objectforms.com/">ObjectForms</a> library would be best served as .JAR library thus we spent considerable amount of research on the matter in order to have a working solution.<br />
<br />
Lets have a look what it takes to create Android .JAR library and how to access the eventual resources packed into it. There are many myths around this, with some people claiming "it is not possible at all", some of this information is inaccurate. <br />
<br />
First part of the series will cover options in creation of a .JAR file, stay tuned for a link appearing here.Anonymoushttp://www.blogger.com/profile/13260257579662354666noreply@blogger.com0tag:blogger.com,1999:blog-284571584475613915.post-87786737183314508142013-05-30T21:47:00.000+02:002013-05-30T21:47:47.357+02:00Saving time while logging on Android, four key strokes at a timeI guess pretty much every Android developer uses logging system, and thus is familiar with the following page from the Android documentation:<br />
<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhGkk42-fwAAc6cSivEXR70b6HI2cW3ryVi95XEUVgf_7jvC228Va-Tpq_-GDWZ5mlOmqxS9GhhoD2SueZYoRi0r9d5dbXW_diFHlTV_qOSyK8lsfSukS714LcDDd-3eMiFrKjEzfAls6E/s1600/logapi.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="304" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhGkk42-fwAAc6cSivEXR70b6HI2cW3ryVi95XEUVgf_7jvC228Va-Tpq_-GDWZ5mlOmqxS9GhhoD2SueZYoRi0r9d5dbXW_diFHlTV_qOSyK8lsfSukS714LcDDd-3eMiFrKjEzfAls6E/s320/logapi.png" width="320" /></a></div>
<br />
<br />
That means to log a line you use a call like this:<br />
<br />
<span style="font-family: Courier New, Courier, monospace;">Log.i(TAG, "Index=" + i);</span><br />
<br />
Where TAG is defined as:<br />
<br />
<span style="font-family: Courier New, Courier, monospace;">private static final String TAG = "MyActivity";</span><br />
<br />
Proactive developers often don't like the refactoring time bomb of String literal to represent the log tag and often replace it with a following line:<br />
<br />
<span style="font-family: Courier New, Courier, monospace;">private static final String TAG = MtActivity.class.getSimpleName();</span><br />
<br />
Still this is a lot of code to type, plus the "TAG," parameter every time you use the log command in your code.<br />
Well, you probably don't mind extra four characters typed, but if you multiply this by the number of times you scatter this line in your code (which is quite likely a big, big number), it becomes a large chunk of time that can be better spent doing something else, just because the API asks you to provide the value of the parameter that might be obtained for you automatically. <br />
<br />
Let's have a look if there is an alternative. Well, lets just have a similar method, which just omits the TAG parameter. The modified call looks like this:<br />
<br />
<span style="font-family: Courier New, Courier, monospace;">prn.log("Index=" + i);</span><br />
<br />
Plus we don't have to declare the TAG static variable anymore as well. Sounds like a problem solved. But we still want to have the information in the log file about the location of the log message. Where we get this from ? Will we use the magic ? That's definitely one option, but other one is to leverage the Java Exception system, and do the Stack Trace analysis to obtain the origin of the log message. The scenario is quite simple. First we throw a new Exception and surround it with the catch block that will do the Stack Trace analysis:<br />
<br />
What's the catch ? Many of you probably noticed that there is a new object created for every log method call - the new Exception needs to be thrown to get the Stack Trace to analyze. This might be definitely problematic inside the tight loop, but there are ways to deal with this. First, you can shortcut the log message origin inspection (for production environment, for example) or use the excessive object allocation (and subsequent garbage collection calls) to your advantage to spot these tight loops with unintended log calls in them (you most likely don't want to have logs in the tight loops anyway). Another alternative is to resort to the original API: it is still there for you to use and there is nothing wrong with it if you know what is the purpose of explicitly provide the log context information. It just feels stupid to me to do so every single time just because the poor designed API asks you to do so.<br />
<br />
If you liked the idea of the simplified logging on Android, there is easy way for you to hop the train. Just go to the following address:<br />
<br />
<a href="https://github.com/actiwerks/logdroid">https://github.com/actiwerks/logdroid</a><br />
<br />
and either grab the copy of the entire project, or just download the jar file (located at: <a href="https://github.com/actiwerks/logdroid/blob/master/library/bin/logdroidlibrary.jar">https://github.com/actiwerks/logdroid/blob/master/library/bin/logdroidlibrary.jar</a>) and include it in your Android project. All you have to do to make the log system to work is to work is to import the correct package:<br />
<br />
<span style="font-family: Courier New, Courier, monospace;">import objectforms.utils.prn;</span><br />
<br />
Please note that while logdroid is available as the separate open source package in GITHub, it has been originally developed as part of the <a href="http://www.objectforms.com/">ObjectForms</a> framework and it still keeps the original package name. Another aspect of this heritage is that <span style="font-family: Courier New, Courier, monospace;">prn.log();</span> call is platform independent and should work anywhere ObjectForms get ported to in the future. In order to fully integrate it with the native Android logging (including correctly filling the TAG argument), you need to connect the two systems at a start of your Android application or any similar appropriate moment. This can be done by calling the following method of the prn class :<br />
<br />
<span style="font-family: Courier New, Courier, monospace;">public static void setPrinter(LogPrinter myPrinter);</span><br />
<br />
There is implementation of the LogPrinter ready for you, in form of class:<br />
<br />
<span style="font-family: Courier New, Courier, monospace;">actiwerks.logdroid.LogPlug;</span><br />
<br />
All you need to do in your application is inserting this line of code :<br />
<br />
<span style="font-family: Courier New, Courier, monospace;">prn.setPrinter(new actiwerks.logdroid.LogPlug());</span><br />
<br />
and you are done. If you fail to provide this connection, the logging still works but it would resort to the platform neutral bottom line, <span style="font-family: Courier New, Courier, monospace;">System.out.println();</span> which in turn would omit the TAG information.<br />
<br />
Hope you find the simplification to the default Android logging system useful and become a happy user of logdroid library. It only saves four key strokes at a time, but in the long run we hope it would be well worth the investment.Anonymoushttp://www.blogger.com/profile/13260257579662354666noreply@blogger.com0tag:blogger.com,1999:blog-284571584475613915.post-14743032929781826332013-03-19T14:43:00.000+01:002013-03-19T14:43:24.043+01:00Techniques for approximate string matchingSince we are planning to add fuzzy matching of string (user names) to our <a href="https://play.google.com/store/apps/details?id=actiwerks.whoscalling">"Who's Calling?" Android application</a>, here is a list of tools and algorithms that can be useful for this task.<br />
<br />
<br />
<ol>
<li><a href="http://en.wikipedia.org/wiki/Levenshtein_distance">Levenshtein distance</a> we used this years ago in the first <a href="http://www.instruct.eu/">Casus</a> prototype. Levenshtein is tricky name, I rememebered it as Levenstein, but as its Levenshtein distance to original name is just one, it was not too difficult to find the real one ;-) </li>
<li><a href="http://en.wikipedia.org/wiki/Fuzzy_string_searching">Approximate String matching</a> </li>
<li>Somehow related, and very interesting article on <a href="http://norvig.com/spell-correct.html">writing your own spell checker</a> </li>
</ol>
<br />
<br />
This list is no way complete, perhaps there will be a pointer to a follow-up article once there is some progress on the implementation of our text matching solution.<br />
<br />
<br />
Please feel free to add more ideas or pointers in the comments area. Thank you. Anonymoushttp://www.blogger.com/profile/13260257579662354666noreply@blogger.com1tag:blogger.com,1999:blog-284571584475613915.post-22255494083608107692012-10-03T11:03:00.000+02:002012-10-03T11:03:54.472+02:00Windows Mobile ScreenshotRecently found an image of HTC-made Windows Mobile phone taken at introduction party in London, about a year ago. It is interesting that nothing changed since that time.
Microsoft is still wander around the mobile phone railway station, the last train with substantial target audience might be long gone.
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEj2aq9SZaev0fLApL3n-SaCKlpTQRftG3-ZOJFzRrdPRch6KiPidOhiIrQfs8BLp9gQx9JOf7XMmAVli5sSooJmPjyPrIWQedgsX3xFjLW6kUCShLVzibOqClOX1q9GeCr_xtUYUkWoBck/s1600/HTC+Titan+screenshot.jpg" imageanchor="1" style="clear:left; float:left;margin-right:1em; margin-bottom:1em"><img border="0" height="400" width="300" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEj2aq9SZaev0fLApL3n-SaCKlpTQRftG3-ZOJFzRrdPRch6KiPidOhiIrQfs8BLp9gQx9JOf7XMmAVli5sSooJmPjyPrIWQedgsX3xFjLW6kUCShLVzibOqClOX1q9GeCr_xtUYUkWoBck/s400/HTC+Titan+screenshot.jpg" /></a></div>
Anonymoushttp://www.blogger.com/profile/13260257579662354666noreply@blogger.com2tag:blogger.com,1999:blog-284571584475613915.post-62557414572174154082012-02-16T14:39:00.000+01:002013-04-19T15:27:55.296+02:00Sensor Fusion and the sorry state of mobile sensor APILet's talk sensors in mobile phones and the applications that can utilize them. It is interesting topic for me for a long, long time, but the urge to write down my two cents came after seeing very interesting video on Google Tech Talk Channel, named "Sensor Fusion on Android Devices" by David Sachs of InvenSense (hence the first part of the title of this post). Here is the video, it is worth watching.<br />
<br />
<div class="separator" style="clear: both; text-align: center;">
<iframe allowfullscreen='allowfullscreen' webkitallowfullscreen='webkitallowfullscreen' mozallowfullscreen='mozallowfullscreen' width='320' height='266' src='https://www.youtube.com/embed/C7JQ7Rpwn2k?feature=player_embedded' frameborder='0'></iframe></div>
<br />
If you think about mobile sensor API, your first reaction might be that this is old news. This feature has been introduced to the world when iPhone shipped with accelerometers, further refined when next generation included gyroscope as well, there is a bunch of applications that are controlled by motion sensors both in AppStore or Android Market thus it must be easy to develop such apps, users are happy and everything is alright.<br />
<br />
Except none of this is completely true. Accelerometers arrived earlier than iPhone, even with all the years of improvement their input is still unreliable, API usually deals with very raw data, there is no high-level library to detect common motion gestures (famous "shake" gesture being the only exception) or normalized, useful data and as a result the applications using sensors to control them are still limited in scope and hard to use. All of this has been mentioned in the video above. It is really perplexing to see that little effort happened to provide effective, easy-to-use solution ready for mobile developers. This explains the second part of the title. Hope this situation changes, and we'll see true motion control revolution.<br />
<br />
Let's have a look at these points one by one :<br />
<br />
<b>1) Accelerometers are available long before iPhone ever existed</b><br />
My first personal encounter with mobile phone with motion sensor arrived in 2004 in form of Nokia 3220 with <span style="background-color: white; font-family: Arial, sans-seirf; line-height: 18px;">Xpress-on Fun Shell add-on, where accelerometer was installed. <a href="http://www.gsmarena.com/nokia_3220_with_light_messaging-news-44.php">You can see the 3220 phone here</a>. Rather impractical, you had to buy quite expensive accessory, slide it on the device before it was usable...definitely not for the masses. However it was a great platform for experiments and I ported the famous <a href="http://www.ebaumsworld.com/games/play/1140/">"Homerun" game</a> : it was a lots of fun when controlled by motion sensor. As Nokia pretty much abandoned the technology and never made it integral part of the mainstream phones (at least until iPhone meteor hit the Earth) we put the entire project on hold, but I have soft spot for sensor controlled applications ever since.</span><br />
<span style="background-color: white; font-family: Arial, sans-seirf; line-height: 18px;"><br />
</span><br />
<span style="background-color: white; font-family: Arial, sans-seirf; line-height: 18px;"><b>2) Sensors are typically dipped in thick layer of mobile marketing sauce</b></span><br />
<span style="background-color: white; font-family: Arial, sans-seirf; line-height: 18px;">Again, mentioned in the video, it is fascinating to see how many different marketing names the sensors can get really confusing. What 6-axis sensor means really ? Well, we can probably live with one more example of marketing-newspeak, </span><span style="background-color: white; font-family: Arial, sans-seirf; line-height: 17px;">unfortunately</span><span style="background-color: white; font-family: Arial, sans-seirf; line-height: 18px;"> it means that inclusion of some of the sensors is still the part of the marketing "shall we add this $1 chip to charge $50 more for this particular device" game. Sad. Motion sensors needs to be absolute standard across all mobile devices. Hope we are getting there, albeit slowly.</span><br />
<span style="background-color: white;"><span style="font-family: Arial, sans-seirf;"><span style="line-height: 18px;"><br />
</span></span></span><br />
<span style="background-color: white;"><span style="font-family: Arial, sans-seirf;"><span style="line-height: 18px;"><b>3) Raw data are unreliable and hard to work with</b></span></span></span><br />
<span style="background-color: white; font-family: Arial, sans-seirf; line-height: 18px;">It is nice to have access to raw data if you need them, but it is not so nice that quite often this is the only data from sensors that are available, and they need quite a bit of processing before they are any useful. Even if you manage to filter out noise, some sensor data needs to be combined with data from the other sensor to offset errors, and this is exactly what Sensor Fusion is all about. Love that term and hope this will become an integral part of every major mobile OS API. Android platform seems to be heading in the opposite direction. The </span><span style="font-family: Arial, sans-seirf;"><span style="line-height: 18px;">Orientation Sensor has been deprecated in Froyo, citing :</span></span><br />
<blockquote class="tr_bq">
<span style="font-family: Arial, sans-seirf;"><span style="line-height: 18px;"><i>heavy processing that is involved, the accuracy and precision of the orientation sensor is diminished (specifically, this sensor is only reliable when the roll component is 0)</i></span></span></blockquote>
<span style="background-color: white;"><span style="font-family: Arial, sans-seirf;"><span style="line-height: 18px;">as the reason for the move. Now you need to do a bit of computation on your behalf. There is arbitrary Rotation Matrix available and it is possible to get orientation relative to such a matrix. However, it is not specified, if the values from various sensors are corrected in any way...seems they are not. Anyone has any experience with this ? Seems it is still quite easy to get data, that are totally wrong, especially from the magnetometer. </span></span></span><br />
<span style="background-color: white;"><span style="font-family: Arial, sans-seirf;"><span style="line-height: 18px;">On the iOS, the data from the sensors seems to be available in processed form, thanks to "Core Motion" framework, that can provide not only separate data from accelerometer, magnetometer and gyroscope, as well as processed data of both accelerometer and gyroscope fused together. There is </span></span></span><span style="line-height: 18px;"><span style="font-family: 'Courier New', Courier, monospace;">CMDeviceMotion</span><span style="font-family: Arial, sans-seirf;"> class that has </span><span style="font-family: 'Courier New', Courier, monospace;">CMAttitude</span><span style="font-family: Arial, sans-seirf;"> property which holds information about device </span></span><span style="font-family: Arial, sans-seirf; line-height: 18px;">motion and </span><span style="font-family: Arial, sans-seirf; line-height: 18px;">attitude, available either in </span><span style="font-family: Arial, sans-seirf;"><span style="line-height: 18px;">quaternion, rotation matrix or Euler angles form. Seems that iOS currently lacks any support for dedicated linear acceleration sensor, thus such information needs to be extracted from accelerometer and might be inaccurate. </span></span><br />
<span style="background-color: white;"><span style="font-family: Arial, sans-seirf;"><span style="line-height: 18px;"><br />
</span></span></span><br />
<span style="background-color: white;"><span style="font-family: Arial, sans-seirf;"><span style="line-height: 18px;"><b>4) Total lack of standardized motion gestures</b></span></span></span><br />
<span style="background-color: white; font-family: Arial, sans-seirf; line-height: 18px;">Already mentioned that shake gesture is probably the only exception. The lack of other, high-level gestures that can be recognized by the phone OS and intercepted by the application developer in easy-to-use way, really limits what might be possible to achieve with sensor controlled applications. We need this to see new stream of applications that can be used even without direct eye interaction. </span><br />
<span style="background-color: white; font-family: Arial, sans-seirf; line-height: 18px;">On iOS, only Shake gesture is currently recognized, an it is mapped to the </span><span style="line-height: 18px;"><span style="font-family: 'Courier New', Courier, monospace;">UIEvent</span><span style="font-family: Arial, sans-seirf;"> (same event type as other events such as multitouch events), which is rather strange. On Android platform, there is no support for any motion gesture recognition at all.</span></span><br />
<span style="line-height: 18px;"><span style="font-family: Arial, sans-seirf;"><br /></span></span>
<span style="line-height: 18px;"><span style="font-family: Arial, sans-seirf;">Edit: Added link to the <a href="http://www.samsung.com/us/support/supportOwnersHowToGuidePopup.do?howto_guide_seq=5646">Samsung proprietary kinetic gestures</a></span></span><br />
<span style="line-height: 18px;"><span style="font-family: Arial, sans-seirf;"><br />
</span></span><br />
<span style="font-family: Arial, sans-seirf; line-height: 18px;"><b>Conclusion</b></span><br />
<span style="font-family: Arial, sans-seirf; line-height: 18px;"><br />
</span><br />
<span style="font-family: Arial, sans-seirf; line-height: 18px;">Let's hope the set of sensors available on even most basic phones will only grow, and they will become a true standard, such as (multi)touch screen is one now. At the same time, let's hope that quality of the data provided by the sensors will improve, using the techniques mentioned in the video above.</span><br />
<span style="font-family: Arial, sans-seirf; line-height: 18px;">We believe that the last point is the most pressing problem : the lack of set of motion gestures, that are understood by the users on one hand (i.e. the UX across applications and perhaps across platforms is consistent) and they are easy to recognize for the application developers (ideally by calling one line of code). </span><br />
<span style="font-family: Arial, sans-seirf;"><span style="line-height: 18px;">To facilitate this lengthy and tedious process, we would like to take an active approach. First, we looking for other people, both designers, developers or users, who see the importance of the common motion gesture library - please get in touch. Second, we would like to announce start of active development in this area...there will be a tool, that will help to explain, record and collect motion gestures in order to understand them better and eventually start a web site that will serve as a collection of such gestures. Watch this space for further announcements.</span></span>Perpetum Designhttp://www.blogger.com/profile/07044191639104974132noreply@blogger.com0tag:blogger.com,1999:blog-284571584475613915.post-88719345316522264002011-08-08T12:50:00.008+02:002011-08-08T23:41:49.115+02:00The Strange Case of Dr. Action and Mr. BarLately, I've been trying to finally update the behavior of the ObjectForms Demo application on the Honeycomb tablet and one of the missing pieces was support for the ActionBar, the new feature of Honeycomb. Well, not that so new feature. ActionBar was promoted by Google engineers (<a href="http://www.google.com/events/developerday/2010/prague/sessions/excellence-in-android-ux.html">such as this one</a>) even before Honeycomb was published.
<br />
<br /><a onblur="try {parent.deselectBloggerImageGracefully();} catch(e) {}" href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgY6eRQZp8f1EpFu8lx9_0icwqGaglobqDbUNM6DupvCXpqKIloWXMEq6G1JavX5ctsP6fMVUXJAuQovvy74_QyGS1Xfsw107TV5W4s023v7ND96gSfGPMRTIf3zrD0Dyutstm8MgskVTE/s1600/Custom+factory+land.png"><img style="display:block; margin:0px auto 10px; text-align:center;cursor:pointer; cursor:hand;width: 400px; height: 240px;" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgY6eRQZp8f1EpFu8lx9_0icwqGaglobqDbUNM6DupvCXpqKIloWXMEq6G1JavX5ctsP6fMVUXJAuQovvy74_QyGS1Xfsw107TV5W4s023v7ND96gSfGPMRTIf3zrD0Dyutstm8MgskVTE/s400/Custom+factory+land.png" border="0" alt=""id="BLOGGER_PHOTO_ID_5638532950963065346" /></a>
<br />
<br />As many other app developers, ObjectForms tried to be a good Android citizen and followed the Google provided advice, so there is a custom implementation of the ActionBar related functionality for a quite some time and I thought since I crafted my interface to look similar to actual Honeycomb API so I thought this will be piece of cake.
<br />
<br />With some awkward reflection and dynamic invocation code (I wanted the same codebase to work on pre-Honeycomb as well) I was set to go. To my surprise, I the ActionBar was not showing up on the Motorola Xoom device no matter how hard I tried. The ActionBar was not there and this call :
<br />
<br /><blockquote>public ActionBar <span style="font-weight:bold;">getActionBar()</span> of the class <span style="font-weight:bold;">Activity</span> (<a href="http://developer.android.com/reference/android/app/Activity.html#getActionBar()">see the API</a>) </blockquote>
<br />was returning no value.
<br />
<br />Neither <a href="http://developer.android.com/reference/android/app/ActionBar.html">ActionBar documentation</a> nor the <a href="http://developer.android.com/guide/topics/ui/actionbar.html">ActionBar developer Guide</a> gave any relevant answers. I learned some interesting aspects about the ActionBar design.
<br />
<br />First, documentation says that if the ActionBar is visible or not, is controlled by the changes of (!!!!) <span style="font-weight:bold;">visual theme !</span> WOW, that's example of very bad engineering. Sure I did try to apply the correct theme, but it made no difference.
<br />
<br />Second thing that I found very unusual was the fact that ActionBar, although very visual component itself, able to contain other visual components (tabs, custom components etc.) is not part of the visual hierarchy and is not descendant of View class, but rather just plain Object. It made no sense to me.
<br />
<br />I was ready to find some workaround. Let's keep my original, custom ActionBar, and just put the button that would show the menu - once you declare in the Android manifest that you target Honeycomb device the "compatibility" menu (located in the bar on the bottom of the screen, next to the "Back" and "Home" buttons) is gone and you can only access it from the ActionBar (in the top right corner). But to my great surprise, the method :
<br />
<br /><blockquote>public void <span style="font-weight:bold;">openOptionsMenu()</span> of class <span style="font-weight:bold;">Activity</span> (<a href="http://developer.android.com/reference/android/app/Activity.html#openOptionsMenu()">see the API</a>)</blockquote>
<br />
<br />was doing nothing, although it worked perfectly well on the Gingerbread and earlier Android devices. Hm.
<br />
<br />Typically, I would explore the Android source code to see what might be the reason for that unusual behavior, but Honeycomb is not quite open source ;-( so I was out of luck there. Seems I hit the wall.
<br />
<br />The next effort was to understand what the hell this visual theme actually does to hide the ActionBar. Problem was, that content of the theme is not public either. But trying to search for any clues, I got to <a href="http://stackoverflow.com/questions/5914791/android-3-0-action-bar-dont-want-to-go">this page</a> that helped me to solve the entire mystery. Yeah, title might be that important attribute. As I had my own implementation of ActionBar on the top, I wanted to maximize the available space and asked the window manager to hide a title for me. With single line of code commented out :
<br /><blockquote>
<br />if(android.os.Build.VERSION.SDK_INT < 11) {
<br /> requestWindowFeature(Window.FEATURE_NO_TITLE);
<br />}
<br /></blockquote>
<br />And the magic is gone and Honeycomb ActionBar is there. It is really just a glorified title bar, so it must be visible in Honeycomb to behave correctly. This little fact is mentioned in the Android Honeycomb documentation, so this is my first take-away for people trying to cope with the same problem :
<br />
<br /><blockquote><h2><span style="font-weight:bold;">Make sure that title of window is visible if you want to show the Honeycomb ActionBar !</span></h2></blockquote>
<br />
<br />Since I believe most developers face the similar scenario I had, they have their own implementation of the ActionBar for Gingerbread and as the result they had a window without the title, the solution Google has for the Honeycomb is extremely unintuitive. Glad I found a solution.
<br />
<br />Not only this, but to my surprise I found that <span style="font-weight:bold;">openOptionsMenu()</span> started to work as well. That's amazing !
<br />
<br /><a onblur="try {parent.deselectBloggerImageGracefully();} catch(e) {}" href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEju-j0wSeS7wXElbTU7r2L70KBz8mzaUHieRKgfDZJWvmhSDUJ5Bwkg1bxsRU_6stzu2tM59_G61uypQXI7ReavRXerJQ0GvEsB9bECQKLbGla9kpjbuQ2ILwfsWko8nsfn4ny9Aj1K3GM/s1600/Company+Info+Double+ActionBar+HC+land.png"><img style="display:block; margin:0px auto 10px; text-align:center;cursor:pointer; cursor:hand;width: 400px; height: 250px;" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEju-j0wSeS7wXElbTU7r2L70KBz8mzaUHieRKgfDZJWvmhSDUJ5Bwkg1bxsRU_6stzu2tM59_G61uypQXI7ReavRXerJQ0GvEsB9bECQKLbGla9kpjbuQ2ILwfsWko8nsfn4ny9Aj1K3GM/s400/Company+Info+Double+ActionBar+HC+land.png" border="0" alt=""id="BLOGGER_PHOTO_ID_5638599625309182578" /></a>
<br />
<br />But I was still not done. As you can see from the picture above, the first version had both native Honeycomb ActionBar and the custom Gingerbread one.
<br />I wanted to reorganize my code to be more reusable and in middle of this I realized the ActionBar is gone again, the <span style="font-weight:bold;">getActionBar()</span> is returning nothing again. But I was able to track my changes, so it didn't take long to figure out what is problem this time. I tried to create my visual hierarchy first and expected that getActionBar() will tell me if I have native HoneyComb ActionBar or not. But this method is useless, as it assumes <span style="font-weight:bold;">setContentView(view)</span> has already been called. Since I was just constructing that view, this was not the case. Of course, this is another quite important aspect never mentioned in the documentation.
<br />
<br /><span style="font-weight:bold;">Hey Google, if your code requires the contract, and you are not able to enforce it by API design, please do us a favor and let us know about the contract !</span>
<br />
<br />So this is my second take-away as the case gets some clarification :
<br />
<br /><blockquote><h2><span style="font-weight:bold;">Make sure the setContentView(view) has been already called for your Activity, otherwise getActionBar() will return null.</span></h2></blockquote>
<br />
<br />Just to make the story complete, I wanted to have the look of the native ActionBar to be similar to previous version, and wanted to replace the logo with one that doesn't look as been a part of the button. I was not shocked to learn that customization is possible only in form of replacing the XML attribute "logo" with a custom value, and there is no corresponding Java API for that. It is still not clear to me why ActionBar is not descendant of View and why it is so difficult to deal with it, but apart of that, all the mystery has been solved.
<br />
<br /><a onblur="try {parent.deselectBloggerImageGracefully();} catch(e) {}" href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiVF_95aZObGnS0csd3-1ifPc81-uEi5jK1i03Q9MMfWxvYxWRFtRpObu9YnqMzJhn4RqqODj1IUuRcIkICe-0NDg-1jOTWgfq4WRYLrFCQ7OG2StqOkqJ71F50p9FCtfvyd9JbjiGHgKQ/s1600/TestObject+HC+land.png"><img style="display:block; margin:0px auto 10px; text-align:center;cursor:pointer; cursor:hand;width: 400px; height: 250px;" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiVF_95aZObGnS0csd3-1ifPc81-uEi5jK1i03Q9MMfWxvYxWRFtRpObu9YnqMzJhn4RqqODj1IUuRcIkICe-0NDg-1jOTWgfq4WRYLrFCQ7OG2StqOkqJ71F50p9FCtfvyd9JbjiGHgKQ/s400/TestObject+HC+land.png" border="0" alt=""id="BLOGGER_PHOTO_ID_5638600508247041618" /></a>
<br />
<br />As you can see, I decided to solve this customization problem by hiding the native ActionBar and rely on the fact that menu button in the top right corner works as expected. In this context, perhaps you'd think that I could save a lot of hassle and skip the ActionBar completely. There is one important aspect, which is the third and final take-away from this post :
<br />
<br /><blockquote><h2><span style="font-weight:bold;">If you target Honeycomb in the manifest, you need native ActionBar to be at least hidden, otherwise there is no way to show the option menus.</h2></blockquote>
<br />
<br />Hope you find the information mentioned in this post useful and hopefully they can save you some head-scratching time I had recently.
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />
<br />Anonymoushttp://www.blogger.com/profile/13260257579662354666noreply@blogger.com7tag:blogger.com,1999:blog-284571584475613915.post-81453001418431264572011-06-14T16:29:00.000+02:002011-06-14T16:29:50.130+02:00Android vs. iOS Battery-related MythsApple just recently introduced the new version of its mobile operating system, iOS 5. Among many enhancements that were announced, the ones that caused the most attention are definitely the new notification system and introduction of more powerful (and more complex) lock screen. Especially the notification centre resembles the system used by Android for several years (some call it a blatant rip-off) and lock screen is now also closer to what can be found on many other "smartphones".<br />
<br />
These new features fueled somewhat dying discussions about possible introduction of still-missing "widgets" to enhance spartan Springboard home screen of iOS and the evergreen debate concerning the differences of implementation of the multitasking and the its availability for the third party developers.<br />
The old demon of presumed better energy efficiency of the iOS implementation got a sprinkle of the fresh water and it become a popular argument of the iOS supporters once again, so perhaps it is good time to have a closer look at many myths that surround the multitasking implementation in the respective operating systems.<br />
<br />
<div class="separator" style="clear: both; text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEi1qZHy_BOY4uY5u8rFp8DcFcgitEOb-ZGtB-H0j3wnKDmg3L8gI-K4l810eM3OK52mY-Mc5IKc3Ge30Q9R1GooNcfERiA1NBM-nSEU1CIp_Hl5TOOIw6GfhDU6ZZnZdRGksqseM_FZDLEP/s1600/Widgets+on+iOS.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="237" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEi1qZHy_BOY4uY5u8rFp8DcFcgitEOb-ZGtB-H0j3wnKDmg3L8gI-K4l810eM3OK52mY-Mc5IKc3Ge30Q9R1GooNcfERiA1NBM-nSEU1CIp_Hl5TOOIw6GfhDU6ZZnZdRGksqseM_FZDLEP/s320/Widgets+on+iOS.png" width="320" /></a></div><br />
<div style="text-align: center;"><a href="http://www.9to5mac.com/71778/jailbrakers-crack-ios-5-notification-center-widgets/"><span class="Apple-style-span" style="font-size: xx-small;">Widgets on iOS are definitely possible, if you don't mind jailbreak</span></a></div><br />
Let's kick-off with the facts. Both iOS and Android are (relatively) modern OS, based on strong, battle tested cores (BSD Unix in the iOS case, mobile optimized Linux version for Android) running on modern, powerful hardware, that makes any form of multitasking perfectly possible. Both OS are built around multitasking and it is used by the System software.<br />
<br />
Both systems are heavily optimized for the mobile usage. Not only the power consumption is of a big importance, there is strong focus on availability of the system resources in case of urgent need : if there is a immediate demand for the uninterrupted processor power, such as in the case of the incoming call (which is top priority to be handled without interference from whatever tasks that may be keeping the CPU busy). Both systems are very able in that regard and the entire OS metaphor is build around idea that app might exit expeditiously - in both cases there are very few states, there are no dialogs that expect the user to explicitly confirm to complete the current action, there is no "Quit" command in the menu etc.<br />
<br />
<div class="separator" style="clear: both; text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhsK-CW6RZCTbIORFORKAXpoWwaeQjbdQvczhucuIbH74HfXdXMvaVOxnR_0LYIMCgwgMnVQYsj2fnIdz3UJ1Nd2FmwnrAd25CEy5pozi3ZhSHgRN6RkdSq7TrmIVkPKxnG8P0f378rCuGx/s1600/Colored+Screens.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="95" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhsK-CW6RZCTbIORFORKAXpoWwaeQjbdQvczhucuIbH74HfXdXMvaVOxnR_0LYIMCgwgMnVQYsj2fnIdz3UJ1Nd2FmwnrAd25CEy5pozi3ZhSHgRN6RkdSq7TrmIVkPKxnG8P0f378rCuGx/s320/Colored+Screens.png" width="320" /></a></div><br />
<div style="text-align: center;"><a href="http://jsharkey.org/blog/2010/07/01/android-surfaceflinger-tricks-for-fun-and-profit/"><span class="Apple-style-span" style="font-size: xx-small;">Android engineers spent quite a lot of time optimizing the platform for the power consumption</span></a></div><br />
iOS metaphor was initially designed to be very simple. There was no sense of multitasking at all, this was only introduced later, and in quite a limited form for the third party software running on iOS. Apple hype machine tried to sell this as paramount feature as being super power efficient. Developers are irresponsible idiots, the system needs to make sure no resources are wasted so only a very special, limited form of background activity is permitted for third party, was iOS mantra and at the same time Apple tried to depict their rival as total battery hog driven by many apps that all arrogantly eat precious juice of the pesky green bot machines even if there is no real need to do so. We are so much better designed system, was the conclusion of iOS supporters.<br />
<br />
Wait...it is not that apps on Android live happily in the background and all they do is ruin the battery life. As mentioned earlier, both platforms apps are designed to be ready to die at any given moment. That moment usually comes right when the user navigates away from the given application to another one. It is usually suspended, or straight killed. The happy live in the backyard bush is only granted to special code on Android too, known as services. There are rules for them too and service is not automatically granted unlimited resource access. However Android gives developers more freedom to suck the battery, based on idea that perhaps there are situations where user really wants to use apps that do some intensive tasks in the background for a limited period of time and are OK with the reduced battery life. If they fathom that their device run on single charge is too short, Android gives them ways to track the offending piece of code quickly and take action (uninstalling, one-starring, even mailing the developer until order is restored).<br />
<br />
<div class="separator" style="clear: both; text-align: center;"><a href="http://hi-android.info/docs/images/service_lifecycle.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="320" src="http://hi-android.info/docs/images/service_lifecycle.png" width="265" /></a></div><br />
<div style="text-align: center;"><span class="Apple-style-span" style="font-size: xx-small;">Android service lifecycle</span></div><br />
But that "we are more efficient" illusion of iOS is not something its fans want to cede easy. The stronghold argument of the power consumption superiority remains the home screen and widgets. New lock screen of iOS 5 might be seen as precursor of third party widgets coming soon. "Never, widgets are just catastrophe, ever updating on the background". This is just another myth. Lets have a look at the following :<br />
<br />
How Android can be more power efficient, despite widgets and more relaxed rules for services ?<br />
<br />
"Impossible, we are the best" is the short answer from the iOS camp. Well perhaps not really. Let's go for more arguments. "iOS is build around notifications, your application get will start once there are new data for it, no need to poll the server. iOS rocks !"<br />
<br />
This is true. It is also true that very same system is available on the Android too, no need to poll the server either. But wait, there is actually more. Android is build about idea of small pieces of code, Activites, that constantly share information through the mechanism called Intents. OS provide a wide array of such data on its own, through system called Event Broadcast.<br />
<br />
"Ha ! Another battery life trap ! Android developers constantly run some code, while the iOS is quietly conserving power". Well not quite like that. Sure, if you execute some code in Broadcast filter, this means extra consumption, but this code is super light. On the other hand, it gives the developer information, that is not available to third party software on iOS and must be obtained by - guess what - polling. If your application wants to do something special if some event just happened, it can, just running that little snippet of code. Say there is some other application trying to get the latest GPS location - listen for this type of event and your application can get the the most accurate location info for free. Another example : your application needs to send some stuff to the server. Again, if time of delivery is not that critical, wait for some other application to establish the network connection (which is expensive operation in terms of battery life) and take opportunity to bundle some data while radio is on. This is how a lot of battery life can be saved.<br />
<br />
<div class="separator" style="clear: both; text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgQtM8ixGmQKq-P2IT9jFGIzKA5Yba7-jvUuATI1Z48WSo-Nn9A3h8We_Zkbtn9Wf8BTyVBQKRHmpjTlI_KklkGBRnqy0f7AlcFxEk66LKN7rSB5VLzYJBvyMmKMz_aW1utwog4Zjdb9nLc/s1600/battery+monitor.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="320" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgQtM8ixGmQKq-P2IT9jFGIzKA5Yba7-jvUuATI1Z48WSo-Nn9A3h8We_Zkbtn9Wf8BTyVBQKRHmpjTlI_KklkGBRnqy0f7AlcFxEk66LKN7rSB5VLzYJBvyMmKMz_aW1utwog4Zjdb9nLc/s320/battery+monitor.png" width="191" /></a></div><div style="text-align: center;"><span class="Apple-style-span" style="font-size: xx-small;">Android battery profiler reveals most juice is lost thanks to display. If you want to save power, don't use the damn device !</span></div><br />
The best proof this is a viable concept is the fact that Apple is introducing similar concept in the latest iterations of iOS and developers can register at the NSNotificationCenter, however it is still quite limited in comparison to Android system-wide mechanism. <br />
<br />
We, developers at Perpetum Design are super serious about the quality of our apps, and the impact the application has on the battery life of the device is an integral part of our design decisions. There were multiple cases when we were able to convince our customers to tackle the problem differently just because of the battery life concerns.<br />
<br />
We believe most of developers think that way, thus more flexibility you have as the developer, the better for the entire ecosystem. Fortunately, the OS vendors seems to understand this too, and iOS and Android are looking more and more similar in that regard.<br />
<br />
Hope this article helped to get light on some of those myths that surround differences between mobile platforms and their battery life related architecture and performance.Perpetum Designhttp://www.blogger.com/profile/07044191639104974132noreply@blogger.com3tag:blogger.com,1999:blog-284571584475613915.post-64685000248200994072011-05-07T19:16:00.002+02:002011-05-07T19:19:28.172+02:00Android spotted in the Apple AppStore<a onblur="try {parent.deselectBloggerImageGracefully();} catch(e) {}" href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhfAM21aLVPO15hsscWICzKB62stvjzVdWKaCJezeteOwH4035ZCmjsNimRoc49c_vqx6zKoL5kAAlWf2W8R4R3bZ-Dp93cVDJvBNLfxrRoz2DYhfZQbHj3kZBPHZwsJJcZQYMYgOgxQo4/s1600/Android+in+AppStore%2508%2508%2508.png"><img style="display:block; margin:0px auto 10px; text-align:center;cursor:pointer; cursor:hand;width: 400px; height: 300px;" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhfAM21aLVPO15hsscWICzKB62stvjzVdWKaCJezeteOwH4035ZCmjsNimRoc49c_vqx6zKoL5kAAlWf2W8R4R3bZ-Dp93cVDJvBNLfxrRoz2DYhfZQbHj3kZBPHZwsJJcZQYMYgOgxQo4/s400/Android+in+AppStore%2508%2508%2508.png" border="0" alt=""id="BLOGGER_PHOTO_ID_5604024917745803394" /></a><br />Not just ordinary Android, but SuperAndroid. Thought this word is complete tabu there. WrongAnonymoushttp://www.blogger.com/profile/13260257579662354666noreply@blogger.com0tag:blogger.com,1999:blog-284571584475613915.post-18460902573972310932011-04-28T11:18:00.000+02:002011-04-28T11:33:59.731+02:00Honeycomb Live Wallpaper Icon mystery<div style="text-align: center;"><br /></div>Trying to create a correct icon for a live wallpaper now. To my great surprise, this is not really documented anywhere, thus I assumed the default 96 x 96 pixels icon will do just fine (after all, this is the size of the icon for the example live wallpaper project shipped with Android SDK. Everything seems to be just fine on the phone (including Gingerbread), although I noticed that other icons tends to be just rectangular "screenshots" instead of icons - again this is nowhere documented.Just did a quick test on the Xoom tablet, and to my another surprise, the icon looks completely ugly. Honeycomb seems to use 208 x 192 as the size of the icon (or rather thumbnail) which explains why the 96x96 icon looks so ugly (see the picture) :<div><br /><div><img src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhou9VPpj-q1LES9fJ5uddQ66iMlSaEiBUqlTWUUjMHRdDRcnkw8Rsqt6DyKTt0R-AfovEm8tNwr2BQHNcAtBUq8YNuDT8__KJfveIRJMJck5UGscHLJezUUU8xT31E1vsDd4WWVFUfyKY/s320/screenshot_honeycomb.png" style="display:block; margin:0px auto 10px; text-align:center;cursor:pointer; cursor:hand;width: 320px; height: 200px;" border="0" alt="" id="BLOGGER_PHOTO_ID_5600564521262888498" /></div><div><br /></div><div>Hope we'll get the updated documentation soon and this guess work will be a thing of the past. </div><div><br /></div><div>Any comments on this topic are very welcome.<br /><div><br /></div><div><br /></div><div style="text-align: center;"><br /></div></div></div>Anonymoushttp://www.blogger.com/profile/13260257579662354666noreply@blogger.com1tag:blogger.com,1999:blog-284571584475613915.post-33054278668338533182011-04-12T10:24:00.000+02:002011-04-12T10:24:02.471+02:00What is HTC brewing ?Interested to see what will come out of today's HTC event in London. Can't wait, in fact. They do some pretty interesting mobile hardware lately.<br />
<br />
Even more interesting (at least for me) was to see the invitation for this event. See the original HTC artwork :<br />
<br />
<div class="separator" style="clear: both; text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhs_Ag0refz4njhkDm4qBrSRDqSBlo_voXn4jEnAFb951S4Vajm4qZWt_dvOpBbzev369lf9JsQMxjeRnTe1nep-rd3_UwzKcA3MwZdpN0-TSsJVCFTZOt1H4MSh3hQTOv66JP1wipE1xnI/s1600/11x0331htcinvite.jpg" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="181" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhs_Ag0refz4njhkDm4qBrSRDqSBlo_voXn4jEnAFb951S4Vajm4qZWt_dvOpBbzev369lf9JsQMxjeRnTe1nep-rd3_UwzKcA3MwZdpN0-TSsJVCFTZOt1H4MSh3hQTOv66JP1wipE1xnI/s320/11x0331htcinvite.jpg" width="320" /></a></div><br />
<br />
And compare it with a slide from my recent talk at the Droidcon conference in Berlin in March :<br />
<br />
<div class="separator" style="clear: both; text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEi8hcH6FuuME_IMAgXAnE2bg-X2EEtiBJocbyhhXH7plkSK0Xxojfvuw4x3iuUeOoEZKqqgbcIcJzsvdhI6XaTN3MQIEzpXm97i-76rOcL2eeor-qRJECk1rX29mhVN494FQQzFR6wQtj9X/s1600/Efective-Android-Programming-with-ObjectForms---new.010.jpg" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="240" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEi8hcH6FuuME_IMAgXAnE2bg-X2EEtiBJocbyhhXH7plkSK0Xxojfvuw4x3iuUeOoEZKqqgbcIcJzsvdhI6XaTN3MQIEzpXm97i-76rOcL2eeor-qRJECk1rX29mhVN494FQQzFR6wQtj9X/s320/Efective-Android-Programming-with-ObjectForms---new.010.jpg" width="320" /></a></div><br />
Can you spot 7 differences ? My talk was just days before HTC sent out the invitation, any chance they were in my audience ;-) ?<br />
<br />
Giving the similarities in our approach to design, it is very likely ObjectForms will run just fine on the latest HTC toys, assuming they release something new with Android onboard.Perpetum Designhttp://www.blogger.com/profile/07044191639104974132noreply@blogger.com0tag:blogger.com,1999:blog-284571584475613915.post-29582266741069177822011-03-31T11:20:00.000+02:002011-03-31T12:09:02.721+02:00GWT Code GeneratorsPlanning to do a future version(s) of ObjectForms, based on Google Widget Toolkit, that will have the same API as the Android version that is to be published soon. <div><br /></div><div>For that to happen, GWT needs to have ability to use more complete reflection available on the client (since the UI is created on the client at the runtime). Right now, the prototype is using great library from Robert "Kerberos" Cooper, the <a href="http://code.google.com/p/gwittir/">Gwittir</a>, which has some support for runtime reflection, but it is far from complete. Most notably, the reflection of Annotations is missing completely. </div><div><br /></div><div>I thought that Google GWT team is going to add those features to the core GWT one day, but it seems this is not on their to-do list at all, so we'd need to write the Annotation reflection support by ourselves. </div><div><br /></div><div>Looking for someone who might be interested to do the same thing, we can join the forces perhaps ? </div><div><br /></div><div>There might be a future <a href="https://groups.google.com/group/czech-hackathon-group">Czech Hackathon Group</a> session devoted to this, if we can get enough interested participants.</div><div><br /></div><div>Here is the (ever expanding) list of pointers to documentation, tutorials and related articles : </div><div><br /></div><div><br /></div><div>Gwittir introspection : <a href="http://code.google.com/p/gwittir/wiki/Introspection">http://code.google.com/p/gwittir/wiki/Introspection</a></div><div><br /></div><div>Generator abstraction in Rocket GWT library : <a href="http://code.google.com/p/rocket-gwt/wiki/Generator">http://code.google.com/p/rocket-gwt/wiki/Generator</a></div><div><br /></div><div>(former) Lombardi Generator experiments blog : <a href="http://jectbd.com/?p=48">http://jectbd.com/?p=48</a></div><div><br /></div>Anonymoushttp://www.blogger.com/profile/13260257579662354666noreply@blogger.com1tag:blogger.com,1999:blog-284571584475613915.post-40143650956935610432011-03-29T12:14:00.000+02:002011-03-29T12:14:09.556+02:00Random notes from Droidcon in BerlinGlad to be able to visit Droidcon in Berlin last week and had a chance to talk about Effective programming for Android and the <a href="http://www.objectforms.com/">ObjectForms framework</a> for Android that I am busy at getting ready for the public release. Thanks everybody for coming, it was great to see the auditorium packed and even better to get so many positive feedback and questions. Can't wait for ObjectForms to get released and that date is near.<br />
<br />
I had a chance to attend a couple of other presentations, and more importantly, meet and talk to bunch of interesting people during the conference. Here are my observations and notes, in no particular order :<br />
<br />
<br />
<ul><li>the quality of talks was very fluctuating. Some of them were absolute gems, at some I just said "I want my half-hour back". More on this later</li>
<li>Motorola Xoom looks pretty impressive, but it is no "iPad killer". Honeycomb doesn't look too intuitive, even to the Android user. New "holo" theme is a mess.</li>
<li>Speaking of Xoom, Motorola scheduled two developer events in April (Berlin & London). Hope Xoom is available by then. It is a real shame that manufacturers can't do a global launch.</li>
<li>There was a bunch of companies offering alternative app markets or payment options. Most of them had hard time to explain why ordinary developer should bother. </li>
<li>Lots of companies were hunting for developers. It is great time to be a mobile developer in 2011.</li>
<li>Plenty of various Android devices popping up. My apps work pretty good on all that I had chance to test. No fragmentation issues whatsoever, but <a href="http://flapic.amplify.com/2010/10/19/tweetdeck-ceo-replies-to-steve-jobs-androids-fragmentation-is-not-an-issue/">thanks for asking, Mr. Jobs</a>.</li>
<li>The most impressive device for me was LG Optimus 3D. While I am a big fan of emerging 3D technologies so this is not that much of surprise, the main reason I like the the new LG phone and think it can be truly a breakthrough device is not the ability to see (very narrow) 3D picture on the screen or taking stereoscopic pictures. But it is still the dual lens camera, what makes the phone so interesting. <b>It gives Optimus a new kind of sensor, which is able to analyze the depth information.</b> The device is powerful enough to handle the computations needed to do to analyze the video stream and get the depth info out. The example of poking the AR monster by a finger and its fighting back was super impressive and this was a top moment of entire show for me. </li>
<li>From that perspective, hope that recent rumors that LG is making the "Nexus Tablet" i.e. reference HW implementation holds true. That would be awesome, I am definitely getting one of those babies.</li>
<li>SE Xperia with integrated PSP and HW controls looks nice too. How many see it as a benchwarmer until the NGP is out, i.e. same way I do ?</li>
<li>Another presentation I liked a lot was Michael Straeubig's intro to <a href="http://code.google.com/p/droidar/">Droid.AR library</a> (filling for author Simon Heinen). I see a lot of synergy with what I was doing in my previous projects and hope to pick this up soon.</li>
<li>Erik Hellman's talk was interesting indeed, many fascinating aspects covered. It is not completely clear what is SE's motivation behind many ideas he presented, though.</li>
<li>Sparky Rhode's Honeycomb presentation was the absolute low of the entire event. Basically just a (not very well organized) walkthrough of the Xoom connected to the projector. Developers expect to get more information, not a bunch of plastic robot toys thrown into audience. Still rubbing my eyes in disbelief this came out of Google employee. </li>
<li>Speaking of disappointment, I noticed I am not the only one who is not happy with the state of the Android API and the documentation quality. There was a bar-camp session devoted to problems of the documentation and an ad-hoc initiative to create a site with more quality examples, as you can see the beginners sites flooded with errors copied from the official docs. </li>
<li>I moderated another bar-camp session, devoted to people experiences with data storage. Seems everybody is resigned to live with plain SQL Lite, although nobody really liked this prospect. But there was no interest in simpler options, such as direct persistence of objects, or reusing JSON to store data etc. Interesting discovery to me. </li>
</ul>Perpetum Designhttp://www.blogger.com/profile/07044191639104974132noreply@blogger.com1tag:blogger.com,1999:blog-284571584475613915.post-78986543235792152102010-11-22T19:55:00.000+01:002010-11-22T19:55:40.637+01:00Post Devoxx Coma and new blog systemHello World !<br />
<br />
I made it safe back home from Devoxx conference and decided to shorten my to-do list. One of the items was to create the new blog on the blogger.com system. I can mark this item as done now. More meaningful post (hopefully) to follow soon.Perpetum Designhttp://www.blogger.com/profile/07044191639104974132noreply@blogger.com0