I knew in advance from the release notes that I will have troubles with the content provider because android.net.ContentURI has gone and was replaced by android.net.Uri. What I did not expect, however, is that because of minor schema changes, the layout and manifest XML files also require quite an amount of handwork. What was previously
[ListView id="@+id/android:list"
now has to become
[ListView android:id="@+id/android:list"
(XML mangling because of the blog engine limitations)
This required 7 changes in the layout files of the rather primitive application. The Android manifest was also changed for good. Gone are the class and value attributes and now everything is a name.
Before:
[activity class=".SyncExample2" android:label="SyncExample2"
After:
[activity android:name="SyncExample2" android:label="SyncExample2"]
Overall, 6 changes in the 21 lines of the Android manifest file.
Updating the content provider was really painful. The replacement of android.net.ContentURI with android.net.Uri and other class changes required 20 changes in the very simple content provider with 229 lines. I marked all changes as comments so you can review them in the code.
You can download the example program from here.
And when I thought that everything was done, it turned out that the NotificationManager (that I used fortunately at two places only) has also changed. Transient notifications are widgets nowadays and are created like this:
Toast.makeText(this, "message", Toast.LENGTH_SHORT).show();
In order not to make it boring, the documentation remarks merrily that android.widget.Toast may not be the final name of the thing. And I did not even mention the changes of the undocumented API that the content provider list views use - well, one uses undocumented API at one's own risk.
Overall, seemingly minor changes of API "beatification" cause significant work even on smaller programs. As a bonus, you may marvel at the new UI. Installed applications went to the main screen.
And look at this horizontal menu!
5 comments:
Yes, they've done a lot of changes...
One thing that I can't understand is the purpose of sync providers and content providers in your example...
Oh, it was just my actual example program at hand. I had just written the sync example (see one blog entry below, titled "Synchronization in Android") and I was curious about the porting effort.
Porting the sync part would have been too time-consuming as it uses mostly unpublished API. So I ported the UI part which in itself is really not very useful.
But the purpose was to evaluate the porting effort, not to do something useful. :-)
Ok, thank you for the answer!
By the way.. I have tried to make couple of activities and now I can't understand two things:
1) How should be organized "context" information in the Android? For example, user signed in - where it is ok to store information about his authorization?
2) How should be organized service methods?.. from the previous example - method that takes data from login dialog and makes authorization can require a lot of time and should be done outside of activity.. May be you can point me on some tutorials - it'll be very cool ))))
First of all, regarding tutorials, anddev.org is a great place. You can find its link on the left-hand side column.
You can pass information from activity to activity in the intent's "extra" field which is a Bundle. You can see an example how invocation information is passed from activity to activity in the example program of the this blog entry.
Regarding connection of long-running services and activities, check this entry:
http://mylifewithandroid.blogspot.com/2008/01/hacking-into-androids-bluetooth-support.html
Look for how the Bluetooth discovery simulator updates the UI of the main activity
good work keep it up
Post a Comment