Tag Archives: android

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.

Java Native Interface – Java和C/C++的結合


為了Multi-platform就用了Java Native Interface
外層的Java包著一個C/C++ shared lib
當轉換平台時就把shared lib轉了compilation setting重新compile
然後把shared lib file直接更換了就可以

而在Android中用C/C++的方法就是Java Native Interface了

Ref: http://en.wikipedia.org/wiki/Java_Native_Interface

P.S. Wiki中用“export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:.”確保shared lib linkage,但這不是必需的
在執行時以”java -classpath <path> …”也可以
以減低global variable的使用
減低global variable的原因請看: http://xahlee.info/UnixResource_dir/_/ldpath.html