Android is plugin unfriendly

As I worked for mobile app almost 2 years, I conclude that Android is not a good platform for plugin development, comparing to iOS platform. I always feel painful to integrate any plugin for Android apps. Here are some reasons why.

Manifest.xml vs info.plist

Manifest file just does too much then a configuration file. Every activity/service and permission requirement in Android app have to register itself in it, which causes many plugins to modify this file. By the design pattern of Android SDK, many plugins cannot avoid to do so.

More than one plugins modifying the same file turns out the plugin users to do that manually, which increase the chance of careless mistake and the effort to manage them, or the users will do a template for several plugins, but it is still complicated if there are too many.

In my opinion, I don’t see any point for such registration on Manifest XML. To protect end-user? They won’t care about it. To protect app developer from third-party developer? No it can protect nothing. It would be perfect if Manifest XML does exactly what info.plist does. At least it should be application oriented, but not module oriented. There should be another automatic system to detect and conclude the combined activity/service and permission requirement.

Message in Activity

Such as onActivityResult, must be listened by an Activity, and there is only one active activity at the same time normally. It also causes different plugins trying to modify the only activity class.

Android View Parameter

All parameters of an Android View, such as position, width and height and etc, are stored in a ViewParam, which is an instance of one of the ViewParam classes, depending on the parent view of it. which causes a dependency of plugin component to external component.

Many plugins developer (mostly in iOS) implement a help method to create a view for users, so that the view could be added to the custom view made by the plugin users and it’s done. However, the view parameter cannot be pre-made as the plugin developer don’t know what is the parent view they are using. The plugin users have to hard code the parameters themselves, and have to update that if the view is updated.

May be it’s not fair to compare an old designed Cocoa Framework with a really new Java framework, and Google is so busy about catching up the visual design against iOS. For now a plugin management for Android should be a good idea to be invented.

Note on SplitViewController and Auto Reference Counting

SplitViewController is a easy tool to make a nice interface for iPad, but I have some negative comment on it:

- It is singleton, and it occupy the whole window. I cannot add something else on it. Of cause, it force a simpler design.

- It cause the work flow different between iPhone and iPad version, which cannot be solved by storyboard entirely.

There is a special case for auto reference counting that would produce error:

- make a weak property
@property (weak) UIView* myView

- alloc and assign an instance to it directly
self.myView = [[UIView alloc] init];

- the instance is released immediately!

It is because the reference counting is zero right after the assignment, and ARC don’t recognize that should be retained and auto-released. In order to solve this, change the code to:

- create a local variable to store the newly alloc-ed instance
UIView *view = [[UIView alloc] init];
The reference counting of the instance is 1 and being auto-released.

- assign that to the property
self.myView = view;