Hello Philip, On 11/22/2012 11:56 PM, Philip Lamb wrote:
Yes, since we (ARToolworks) use OSG in our ARToolKit SDKs (across Windows, OS X, Linux, iOS and hopefully soon, Android :-) ), we have to anticipate that the users of our SDK will potentially run on any architecture supported by Android. Intel is making a push with Atom-based Android tablets, so x86 is likely to be more common going into 2013. There are a bunch of low-cost Android devices in China using MIPS.
OK, makes sense. However, I would probably release several APKs in such case, to keep the download sizes down.
On another note made in the thread about attempting to replicate OpenCV's "OpenCV Manager" strategy for Android: to those developing the Android port of OSG, and on behalf of the users, don't do this. It makes for bad user experience. The user just wants to install and run your app, and then has to deal with "what is this asking me to install NOW?" along with the delay, logging in and fiddling with the Android market. We use OpenCV and we have gone to some lengths to statically link OpenCV to as to avoid having to put our users through this. It's basically trying to solve a problem which doesn't exist -- users really don't care that much about a couple of extra MB in size of your app. It also potentially breaks your app if the user installs new binaries including changes which are not completely backwards compatible.
Well, I beg to differ here. The extra download is a very common thing with many games in the Google Market - you download/buy a game and then it asks for an extra 100MB+ download of the game data. So that is hardly an unprecedented feature, moreover it is required by the Market policies that limit the maximum app size, I believe.
Users certainly *do care* about the few extra megs of download - especially those on metered data plans with no wifi in range. Just read the comments under some applications whenever size of the app changes. So any way to cut that down is good - especially on the multi-architecture APKs that contain binaries for all supported architectures (in the worst case 4x larger download ...)
Also the storage size on many devices is quite limited and the trend is to do away with SD Card slots on newer devices, letting the users rely only on internal storage. So if you link your binary statically and the user downloads two, three of your applications, they get all the libraries duplicated. That is what the Manager tried to address, because Android prevents one app from using shared libraries installed by another one directly.
Regarding the potential breakage when OpenCV is updated - that is not supposed to happen, because your app declares which version of OpenCV it needs. The manager then finds and loads an ABI compatible one. At least that is how it is intended to work - I haven't had a breakage so far, despite several updates, but that is no proof, of course.
Finally, linking of OpenCV outside the manager is deprecated and unsupported now, so if something in your app breaks, you are pretty much on your own.
Regards, Jan _______________________________________________ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
