I'm currently trying to use the BBM SDK 1.0 (net_rim_bb_qm_platform.jar).
The integration works no problem, except when the device has a BBM version lower than 6, as per the library's requirements.
I'm wondering if there's some sort of "reflection" type of system I could use to test at startup whether to include the library, which I highly doubt. Or a way to restrict downloads on App World, i.e. if the device has BBM 5, download a version without BBM integration, else download the other.
First, you need to decide whether your app must have BBM, or if it can still run without BBM, in some degraded mode (fewer features). It sounds like your app can run without BBM, so I'll address that scenario:
Take a look a this documentation and sample code from R. Masroor on BlackBerry.com.
From the description (bold is mine):
The RIM supplied BBM dependency checker samples, provide two
approaches to integrating with BBM.
a) The proxy method which is appropriate when the application will not
run without BBM – it directs the user to download BBM.
b) By contrast,
the interface method provides a way for an application to isolate
itself from the BBM, so that the application can still run even if BBM
is not installed.
Why is this isolation needed? Because if a cod (project) references
any BBM methods, then BBM must on the device and at a suitable level
before that cod can be loaded. So if an application directly
references BBM and there is no BBM (or no suitable level of BBM) on
the device, the application will not run.
Of the two approaches, the interface approach is probably the most
useful, as most applications have functionality without BBM. But this
approach has two disadvantages:
• It requires a start up process to
register the RuntimeStore Object
• The layered approach and the use of
call-backs makes this quite complicated for me.
The attached project demonstrates a variation on the interface method,
that creates the interface object at Application start-up, using
class.forName(). Aside from this change, the sample provided is
similar to the interface method, and is explained below. After the
explanation of the attached project, this document explains how to
create a different structure which you may find easier to work with.
Also, for reference, you can take a look at the BBMSDKDemoProxy sample project that comes with the BBM SDK download.
Related
I am trying to develop a library of shared code for my company.
We are developing on a technology by SICK called AppSpace, which is designed for machine vision. AppSpace is a stand alone eco-system, beneath which there comes a variety of SICK programmable devices (e.g. programmable cameras, LiDAR sensors), and an IDE with which these can be programmed. Programs are written in Lua, using HTML/CSS for the front end.
AppSpace provides a Lua API for these devices.
In my company, a few of us write applications and it is therefore important that we create a library of shared code to avoid redundancy / rewritten code.
However, each firmware version of each device has a corresponding API version. That is to say, that on a given device the API can change between firmware versions, and also that API versions differ across devices. Two devices will have two different sets of API functions available to them. Functions they share in common may also have slightly different implementations.
I am at a loss as to how such a situation can be properly managed.
I suppose the most "manual" route would be for each device to have its own partial copy of the library, and to manually update each device's library to have the same behavior each time a change is made, ensuring that each device conforms to its API. This seems like bad practice as it is very error prone - the libraries would inevitably become out of sync.
Another option might be to have a master library, and to scrape the API documentation for each device. Then build a library manager which parses the Lua code from the library and identifies missing functions for each device. This seems completely impractical and also error prone, probably.
What would be the best way to develop and maintain a library of shared code which can be run on multiple devices, if it is even possible?
I would like to answer this and review some of the topics discussed.
First and foremost; functions that are shared in common between devices will be implemented differently by means of the compiled code on the respective device (i.e. PC, 2d camera, 3d camera, LIDAR, etc) while the functionality maintains the same between them all. This way the code can be readily ported from one device to another. That is the principle of the SICK AppEngine that is running on all SICK AppSpace devices as well as 3rd party hardware with AppEngine installed.
The APIs embedded into the devices are called a CROWN (Common Reusable Objects Wired by Name) component and can be tested against nil to determine if they are exposed APIs. Here's an example of an CROWN called 'IMAGE'. If it exists than you could run this code when it does.
if IMAGE then
--do code
end
SICK also has a AppPool that you can upload your source code to and it will test all the required CROWNs and return a list of all SICK devices that can run properly.
I am a developer working on a robotics application for iOS. I do not intend to submit this app to the app store, nor do I have any wish for suggested methods to be apple approved....
I am trying to get bluetooth working, and I think a good place to start is to try modifying the existing apple frameworks. Is it possible for me to modify the frameworks so that when they are built to my iOS device the frameworks will be modified for the app (but not other apps on the same device)?
As a matter of fact, you can!
Objective-C allows you to "swizzle" methods to override their default behavior, and yet still call the original implementation if you want to. You can do this for any number of Objective-C methods, as many times as you want.
If you wish to override behavior that is present in C functions, you will need a little bit more control over the platform. Jailbreaking allows you to use the full power of Jay Freeman's CydiaSubstrate to hook or swizzle both Objective-C methods and C/C++ functions.
While I don't recommend the use of MethodSwizzle per se, the following URL has a good discussion of swizzling http://cocoadev.com/wiki/MethodSwizzling.
But you should really use CydiaSubstrate's MSHookMessageEx and MSHookFunction instead. Especially since you're not submitting anything to the App Store.
Now regarding Bluetooth, I've done extensive work in this field (I developed Celeste, which is a systemwide tweak providing vanilla Bluetooth OBEX support to system apps on iOS). I suggest you look into using something like BTstack, which provides you with access to the bluetooth module from the HCI to RFCOMM levels, and supports things such as SDP and pairing, which you will probably need. It also has the added benefit of not requiring method swizzling, which some people seem to think is some sort of satanic ritual that should be avoided at all costs.
Aside from categories (which extend the functionality of base classes delivered in those frameworks), I don't believe you can "modify" the existing Apple frameworks per se. A better course of action might be to simply create your own framework (or find somebody else's open source, commercial or simply third party framework) and then build that framework into the app that you install onto the iOS devices you want to work with.
Is it possible to create a service using XNA/Windows Mobile 7? Similar to how you can in Android?
This isn't really possible in 7.0, but if you're using (or targetting) 7.1 (Mango), then you can look into using Background Agents. The link explains the base class, but you can use ScheduledTaskAgent, AudioPlayerAgent and AudioStreamingAgent depending on your need. There's a great introductory tutorial here and sample codes on MSDN. There's an XNA specific example in this MSDN post.
The reason Background Agents are used is so that different apps can be monitored to ensure one app isn't hogging all the resources. This means that the battery life is more optimised and there's better resource management.
If you mean to use Services such that others apps can communicate with your service, this isn't really possible. Each app is sandboxed for security reasons and, at the moment, this means that they can't communicate with other third party apps directly.
I've been reading about Andrew Russell's ExEn project and I'm wondering what the flow would be like for creating a WP7 accelerometer-based game and then porting it to another platform, say iOS. Here's what I hope would happen:
Create fully functional game in XNA, avoiding dependance on device
specific items like the 'back' button.
Run the project through ExEn (I have no idea on how this would
happen), creating fully functional iOS game.
Run game on iPhone.
Sorry for that pitiful outline, but I just don't have a solid high-level view after reading about it.
Also, being software conversion, surely it wouldn't totally work. How would you iron out the wrinkles? I assume you'd have to know iOS or Android fairly well to pin it down.
Anyway, if anyone can move me one step closer I would appreciate it.
ExEn is an implementation of a subset of the XNA API that runs on different platforms (including iOS and Android). Put simply, it makes the classes and methods that you use when writing XNA code available to you on these other platforms. (Plus appropriate instructions, examples, etc.)
When using ExEn, the bulk of your code should simply "just work". However in most real-world cases you will need to write at least some platform-specific code (and probably provide some platform-specific assets). In particular to support different device resolutions, and also in cases where you use XNA features not available in ExEn.
At time of writing, ExEn does not implement the XNA/WP7 APIs for accelerometer support. At some time in the future they may be added (either by me or anyone who wants to contribute a patch). ExEn is distributed as source code, so you could even add the necessary support yourself.
The alternative would be to write platform-specific code for the parts of your game that query the accelerometer. Using ExEn does not prevent you from also using the APIs of the underlying platform.
ExEn (on iOS and Android) runs on top of Xamarin's MonoTouch and Mono for Android products. These two products provide C# bindings for the underlying platform APIs. Also, much like ExEn implements the XNA APIs, Mono implements the .NET APIs. These products also provide you with the tools you need (IDE, compiler, debugger, etc).
So the iOS API that you would use is UIAccelerometer (doc). This is exposed in C# via MonoTouch.UIKit.UIAccelerometer (doc). I'll leave looking up the Android equivalents as an exercise.
You can't expect:
porting a game to other platform and don't modify it.
porting a game with special platform inherent abilities to other platform that lacks this abilities, or vice versa
Just got a car with the Microsoft sync system in it. Did a quick search online and was curious if anyone is aware of any SDK that may exist, sample open source add-on applications, etc.
Thanks in advance.
UPDATE:
Looks like Ford has finally released their SDK:
https://developer.ford.com/
Ford has a website SYNC Mobile Application Developer Network but the SYNC SDK does not look to be available yet (their site mentions possibly later this year). It appears they are stilling working on the API before releasing it. All they are offering now is a way to register to be notified of new info as it becomes available.
From their About page:
Ford is hard at work developing an API
to allow developers to integrate their
Smartphone applications with SYNC. The
Developer Program website will educate
developers about the Ford SYNC
platform and how to interact with it
via the API. There will be a full set
of documentation, example
applications, reference libraries, and
even a developer forum so you can
reach out to the community for quick
help.
With the available SYNC API's, mobile
application developers will be able to
do some of the following:
Create a voice UI for your application using the in-vehicle
speech recognition system.
Write information to the radio head display or in-vehicle touchscreen
Speak text using text-to-speech engine.
Use the in-vehicle menu system to provide commands or options for
your mobile application
Get button presses from the radio and steering wheel controls.
Receive vehicle data (speed, GPS location, fuel economy, etc.)
The official API and full website
launch is set to be targeted for later
this year.
It looks like the SDK is coming very soon. The story was just posted on Engadget:
http://www.engadget.com/2009/12/18/ford-to-give-sync-some-app-store-flavor-opening-api-to-devs-in/
Now just imagine what you could do with access to your automobile functionality!
I don't think there is any. Its a closed ecosystem.
http://www.autoblog.com/2009/01/09/ces-2009-sync-could-one-day-add-app-development-like-iphone/
From what I understand it is based on the CE 6.0 platform using windows automotive 4.1, but I could be wrong. We really need a forum to get this going. Hurry up Ford! Release the SDK!
Given the way Windows automotive is there is only two ways of putting a ROM on Sync. Using JTAG to put your own custom bootloader (forget it), or though the USB. Which you will need to know how to sign the file so sync will think it is an OEM ROM. So at this point even if you were able to come up with your own custom rom by using Microsoft eMbedded Visual C++ you would still have no way to get it on there.
BTW, the SDK they are talking about releasing will only be to develop apps for applink. (not modifying the OS). However, to upload the apps we might be able to find out how to sign the .bin file for sync to accept a ROM through the USB.
Then again this is just from my understanding... I am no great developer or anything.
Ford launched sdk in ces, check it out: http://techcrunch.com/2013/01/08/ford-launches-its-openxc-sdk-and-hardware-specs-to-let-developers-access-its-cars-sensors-and-metrics/