blackberry deployment and release process - deployment

So I'm building a blackberry app and was wondering if there is any good documentation on deployment/release best practices? Blackberry's "A70 – How to Deploy and Distribute Applications" document is kind of lacking.
I guess I'm looking for answers for the following question (Specifically for Over-The-Air aka OTA):
I'm building an app for OS 4.5 and up. Do I need to compile a separate COD/JAD for each version? (i.e. 4.5, 4.6, 4.6.1, 4.7, and 5.0)
How do I detect OS version from the user-agent?
What's the best way to compile COD/JAD files?
anything else that might be good to know :)
Thanks in advance!

No you don't need to compile a separate cod file for each version although my understanding is that OS 5 will run older applications in a compatibility mode which can mess things up so you may want to compile separately for that if there are any problems.
According to Wikipedia the user agent seems to follow the format "BlackBerry / Profile/..."
I'm really not sure what you're looking for here. As far as I know the rapc compiler doesn't have any optimization abilities so however you compile it it's going to produce the same result.

Related

Monotouch and Hackintosh

I have developed an app on monotouch-5.2.5 evaluation version.
Now i want to deploy on Apple Store and to do it i have bought a full monotouch version (5.2.10) and i have installed all certificate and provisioning profile.
When try to build my app i have the following problem:
mtouch exited with code 99
i have this configuration:
monodevelop 2.8.6.5
mac os x version 10.6.7 (is an HACKINTOSH)
Do could it be a incompatibity problem beetween HACKINTOSH and MonoTouch?
...This it'll seem strange because i've develop on it without problems.
The Xamarin.Mac / Xamarin.Ios licencing does some kind of hash of the Mac hardware to give your machine a unique ID. This locks the MonoTouch licence to your machine.
I know previously when people have changed hard drives etc. it has broken the key, this is because they use the Hard drives serial number as part of the hash. They may also use hardware MAC addresses and other IDs.
I imagine something they use in a Genuine Mac is not available in your Hackintosh.
Xamarin states on their website they do not support Hackintosh. They claim it is too hard to ensure their compiler works properly in such a system, but they do not stop there. They also make it impossible to install a key on a Hackintosh or on a Mac running in a VM!
I can understand they wont provide support for issues happening in such an environment, but to force developers to buy a Mac is a bad move. Especially considering a lot of their customers choose Monotouch exactly because they are comfortable with Windows/.net already and are not eager to migrate 100% to Mac OS, it is pretty obvious many prefer to work in a VM or use their existing PC hardware.
I used the trial version in a VM without any issues whatsoever, so whatever technical issues they might be worried about seems irrelevent. So I think this is more a political issue than a technical one.
I can only hope they will change their policy, or that someone gets annoyed enough to crack their compiler so that we can all use it the way we prefer.
I have a Hackintosh, I just encountered the same problem, and I also can not login app store, because ethernet card not built-in, I modified the DSDT to complete built-in, it is OK.
It is obvious that you need to contact Xamarin Support because they know better whether this is the exact problem or not. but....
A Statement in Xamarin Page demonstrated that it is impossible to use MonoDevelop/MonoTouch on Hackintosh.
I have some misunderstands that I need to know:
1. What do you mean building? (Bundle/Deploy to device/Build on Simulator)
2. Did you tried deploying to device?
I googled this issue and there are many that had this error code, but their problem was MonoTouch Activation, I think you can reactivate MonoTouch to make sure. (if you want to build on device)
But I do not attribute this error code to Hackintosh, because one of my friends-who is working with Unity (Mono) on Hackintosh, can easily build on device.
Regards,
Peyman Mortazavi

Core Location Simulator on Xcode 4.2 Not Working -Any Clues?

I checked all the other variants of this, and don't see the answer here. It seems a lot of folks are thinking of Xcode 4.1, and the issues therein.
First of all, I am very happy with Xcode 4.2. It fixes the huge plethora of problems I was having, and, once again, makes the simulator a useful tool. I am very glad for this, because it is a MUCH faster workflow than using the devices.
Now, 4.2 introduces something in their Edit Scheme dialog (Go to the "Run" page, then "Options"). This is called "Core Location [checkbox] Allow Location Simulation". It allows you to pick from a list of pre-defined locations.
This seems to obviate the horrendous hack that I had introduced when I first encountered the issue in Lion.
However, it no workee. I'd like to find out what I am doing wrong. Has anyone gotten this working?
Remember: THIS BEGINS IN 4.2, WHICH JUST CAME OUT YESTERDAY. So the rules from 4.0 and 4.1 don't apply. It is a new capability.
Thanks!
First, I created the GPX file as mentioned in this question.
In addition to updating the Run Scheme to select the Allow Location Simulation option and specifying the Default Location as you mentioned, you also need to make sure that your Scheme is set to iPhone 5.0 Simulator. This made the trick for me, when I debug my project, the app asks me if I want to allow it to use my current location, and I can see the Debug -> Location menu in the iPhone Simulator.
There's a thread on this bug in the Apple developer forums. One suggestion is to reset the simulator.

Latest Reachability.m (Example code version 2.2) compatible with iOS 3.0?

Does anyone know if version 2.2 (the latest) of Apple's iOS 'Reachability' example code will run on iOS 3.0?
I want to support iOS 3.0, and Reachability.h and .m is the first non framework code I'm using in my app. In my own code I usually read the docs for all methods I use, and use respondsToSelector: to implement methods that won't run on 3.0.
When people use third party code, how do they confirm which iOS it supports without checking every method individually against the docs?
Alternatively, does anyone know how I can get my hands on the old version of the example code? (Reachability version 2.1 might help.)
I don't mean to snipe an answer from #Matt and #Martin, but I feel like this question deserves an answer for posterity. If they come back and post their comments as answers please feel free to accept them.
Anyway, my own answer is that I would highly advise against using Apple sample projects directly in a production application, especially Reachability. Many of their examples are badly written and, as you've noticed, outdated. I've filed a lot of bugs against them without many results.
That said, one other point is that you should really think twice about relying on Reachability for control logic. If you just want to notify the user when their connection changes or something, okay. But don't rely on what Reachability says to decide whether to try communicating with the network or not. It's often wrong about your network status. Just open up a connection, and if it succeeds great, otherwise you'll get an error response letting you know there's no connection.
EDIT - Regarding your other question about how to tell what IOS a third party app supports. The answer is, unless they've documented it, you might not be able to. Best indicator is usually taking a look at the build target's "Base SDK" and "iOS Deployment Target" settings. Base SDK will be the latest iOS version they've built against, and Deployment Target will be the earliest iOS version they support.
Cheers

Check for new SDK calls?

iOS development is now done using only the latest SDK.
Is there any way to search my code base for calls not present in older SDKs, generate warnings when compiling code that requires newer SDKs, or some other way to find where the code will fail on older iOS versions?
A workaround that broke compiling entirely would also be acceptable. This is not something I want to ship with, just something I want to do to verify that I've handled everything properly. The application seems to run on devices running earlier versions of iOS, but I'd like to be able to prove this.
No, I don't believe that there is a good way to find new calls not available in older SDK's. It's something I've wanted for a while.
The best thing I know of is to test your app thoroughly on a device running the oldest version of the OS that you plan to support.
It looks like this will do it...
Add this to your prefix:
#define __IPHONE_OS_VERSION_MAX_ALLOWED __IPHONE_3_1
Do not ship without removing this, though. In fact, you'll probably have to disable huge chunks of code to get your app to build this way. And even so, the coverage is nowhere near complete. But it's better than nothing.

Is an iPhone SDK patch available, or do I need to download the entire tool set?

I've looked around Apple's site, and searched Google, but I can't find anything. I was wanting to patch the iPhone SDK to version 3.1.2 so I can deploy to my device again. I see the download for the iPhone SDK/Xcode bundle, but I was wondering if there was a patch that wasn't 2.7gb.
Thanks
As far as I've ever been aware, every update to the SDK required a full redeployment of the 2.7GB XCode stack. Of course, "as far as I've ever been aware" dates back to just the 3.0 beta, as I'm a relatively new dev for the platform. :)
I've never seen a patch, I believe that you always download the entire .dmg