10-21-2011 12:23 AM
Basic: Can we make our own "app player"?
Background: When RIM announced the PlayBook, they stated that it would run HTML5/WebWorks, Adobe Air, Native, and have a Android App Player and a BlackBerry App Player. When a webcast was done about the NDK, I asked "Is it possible to make our own app player?" They didn't seem to understand what an App Player was. Regardless, I really like the concept of having what would probably best be called an emulator that runs dedicated apps. So instead of opening the emulator/app player and then clicking open and opening an app, you simply click an app as it is and it will invoke the emulator automatically.
Detailed: So, is it possible with the NDK to make an "app player"? The best version would be the one described above, click on an icon (like any other app) and it opens and an app that would otherwise not run on the PlayBook/BBX would be able to run like any other app.
(Ignoring signing at this moment) The idea I thought about how it would work is to write it similar to the Android runtime and then just "package" the application to a BAR so it can be deployed.
Now if that is not possible, what about writing a "launcher" app so that a "packager" utility could take the app and data, combine it with the "launcher" in a BAR file, then that calls a library which has the actual "emulation" system?
I don't know the internal details on the Android runtime or how the different game engines work (if they use one of the above methods or something different).
What I would want to avoid is basically "You can write a library and then write a separate app that would then call that library".
But that is why I am asking. Is it either of the 2 methods mentioned? The standard library + app (which then defeats the purpose)? Or is it a RIM + partners only thing (at least right now)?
Solved! Go to Solution.
10-21-2011 10:09 AM
10-21-2011 10:51 AM
*shrugs* This is purly conceptional right now. If I had to give a hard concept, I'm a C# dev and would love to try and get the Mono framework running on the PlayBook (or BBX for that instance). But I wouldn't want to have to store a whole bunch of files in the file system, I would perfer to be able to install an app that would have been written in C# and uses Mono. Thus making it seemless for the user to actually use the app.
As for security, that's why I said "ignoring signing at this moment" (though I have used the security explanation on the Java side of the forums myself). How the apps would "end up" on the PlayBook, the process I thought was "user downloads (sticking with Mono for now) a library for developing an app for the PlayBook in C# (if you don't know Mono or .Net, they can both be used for development as they are mostly cross compatable, so I'll ignore downloading that). Person develops and tests app on computer. Then using a "packager", they package the app into a BAR. The BAR file has a native program that actually invokes the player, the "real" app and it's data. The player then runs the app".
So for security, since something like C# would be a managed framework then a simple check can be done to determine if a "secure" API is used, then to require signing. The library can then enforce that (last thing I want is to get in trouble for making a back door). Other options is to just do it at run time (if a secure API is used and the app isn't signed for it, then it throws an exception and requires signing for it. Finally, the easiest one, just require signing regardless of what APIs are used.
10-21-2011 01:09 PM - edited 10-21-2011 01:10 PM
Interesting. Allowing Mono on the device would open up more apps for the system. What I meant by security was not signing, but security of the device (a key to RIM with enterprise solutions). Allowing a 3rd party player may open up security risk to the device and its data. Just like RIM controls the AIR "player" and the Android "player", I'm not certain they would allow 3rd party players without a full security review. RIM is not looking at a Java "player" for the future, so I am not certain if a .net/mono/c# environment would be allowed. As we seen with some apps, RIM gets final approval. If you think getting mono player working at the NDK level might work, dont be surprised if RIM wont approve it (or you can ask in advance, but they would never probably reply unless you were a preferred partner). If you get that to work at a pure R&D effort and then see if RIM would approve it, it would be interesting, but I would think RIM would want control over any app players that would run other apps.
Just my $0.02.
10-21-2011 01:22 PM
Understood. It would have to be a balancing act, how would something like Mono which can do a very large amount of things (including making applications on the fly) work on a platform that is very security conscious. But .Net (which Mono is an open source version of) has AppDomains. Applying those to BlackBerry Balance would potentially solve that issue. Have an AppDomain specifically for the consumer and another for enterprise. Now if the enterprise user says "access the memory of the consumer partition" to open/save a file, the AppDomain throws a security exception. The apps themselves would be in a BAR file and would thus be under normal BlackBerry security. Other checks can be put in place to prevent security holes.
The point of the thread was to see if RIM would allow something like this. Though I don't expect someone from RIM to respond, there is barely any posts here yet so it's hard to miss.
On an additional security through, to get the most performance out of a .Net/Mono, the JIT should be used. But this would require the ability to allocate memory, compile the .Net/Mono application to it, then to execute it. That I have almost no doubt is not and will not be possible but it is something that should be presented upfront.
10-21-2011 04:12 PM
No you cannot do it for security and for brand protection issues. If you want to use shared library, or shared runtime (i.e. if you wrote your own java runtime lets say) you have to package is as "captive" i.e. in your own bar file.
Installing shared resources is not currently supported on platform.
10-21-2011 04:21 PM
Understandable, so I would, as you put, "captive" the app in my own BAR file which happens to have the library for the runtime in order for it to work.
As for "shared resources is not currently supported on platform", the NDK has the option to make a shared library? I expect that this has to be included with the app, but what if multiple apps use the same library? Will the OS use the most recent one or does each app use their own local copy of the library?
10-21-2011 06:18 PM
10-21-2011 09:27 PM - edited 10-21-2011 09:29 PM
I know about the sandbox, I ask because it was an issue I had on the phone side of BlackBerry. I made a couple shared libraries but people didn't really use them because BlackBerry OS wouldn't handle them in a shared library "manner" (App A with lib A. Install App B with lib A and lib A isn't added because it already exists. Uninstall App A and lib A gets removed as well.) I am really hoping they add shared library support because it would make it much easier to actually use the libraries. Because to me, if App A has version 1.0 of a library and App B has version 2.0 of the same library, why should they be isolated to just the apps using them?
Unrelated: Odd, I don't remember marking a solution in this thread, nor do I have the ability to unmark the solution (as you could previously).