December 9, 2009
Posted by dfield in Business, Development, Enterprise mobility, iPhone
A lot of people don’t know it, but there is a way to deploy Enterprise Line of Business (LOB) applications to employee iPhones without using the Apple appstore. It definitely has its caveats. But, it’s worth knowing about.
If your company has 500 or more employees, you can buy an iPhone “Enterprise” developer license. It’s a bit more then the “Standard” individual and company licenses, but not much. For more on developer licenses, go here.
Once you have the license, you can sign your LOB apps with your certificate and provision them to company devices. ”Enterprise” developer licensing allows what is called “Universal” application provisioning. This is the same type of provisioning that is granted to applications deployed through the Apple Appstore and allows deployment of the application to any iPhone on the face of the Earth.
Wow, so with a developer license, you can deploy an app to any iPhone out there without going through the appstore….WRONG! The “Enterprise” developer license EULA that you accepted dicatates that you are only allowed to deploy apps to iPhones operated by employees of your company. Deployment to any other iPhones is illegal. And, I’m absolutely sure that Apple is not going to stand by and let you break the law.
Well, you can deploy your LOB app to your company users and that’s the important thing, right? At this point, you may be wondering how you go about deploying the application to the employee-operated iPhone. There are currently two ways to do it. Use the iPhone Configuration Utility (iPCU) or use Apple iTunes. Both methods are described in the Apple iPhone Enterprise Deployment Guide.
The caveat here is that neither iPCU or iTunes app deployment can be performed directly between the iPhone and a server. Both iPCU and iTunes are desktop applications that run on either a Mac or Windows machine. But, they do support two different scenarios. iPCU is best if you want to setup a bulk number of iPhones with your LOB before giving them to the user. iTunes is better for deployment of the app or on-going updates when the iPhone is already in the user’s hands.
When deploying the LOB app, you have to get your Enterprise Developer License .mobileprovision file installed on the iPhone before you can install a .app file. You can deploy the .mobileprovision file using desktop management that you may have deployed in your network to offload this task from the user. When the iPhone is connected to the desktop running iTunes, the .mobileprovision file will be deployed. Then the user must add the .app to their app library and select to install it on their iPhone.
March 20, 2009
Posted by Marco Nielsen in Development, Windows Phone
After writing up my last blog article about Windows Mobile troubleshooting and logging utilities (see it again here), I was more closely at the lookout for other tools and tricks that might help assist in a similar fashion.. Of course I found some more good additional information and have included it in this round.. Especially the memory management information I don’t think has been that well communicated in the past..
.NET Compact Framework Logging
On Steve Hegenderfer and Reed Robinson’s excellent blog Reed posted a great article about how to enable .NET CF loader logs and what to look out for. Specifically referencing this MSDN information on how to enable the logging: http://msdn.microsoft.com/en-us/library/ms229650.aspx. It is all controlled in specific registry keys on the device to enable 6 different flavors of .NET CF logging: “Interop”, “Error”, “Loader”, “Network”, “Finalizer”, or “Trace”.
The Power Toys for .NET Compact Framework v3.5 download gives you additional tools to make this easier. One is the Remote Logging Configuration Tool:
So the most interesting for non-developers trying to troubleshoot .NET CF applications is probably the “Loader” logging. This is where you can see if the application even makes it off the ground and why. As Reed suggests in the article I mentioned it could be referencing a .NET assembly not present on the device for whatever reason..
Additional details on how to read the “Loader” logging can be found here: http://msdn.microsoft.com/en-us/library/ms229667.aspx.
File System Logging
This is a type of extreme logging that can really slow down a working operating system. But it can also show you exactly what is going on at the file I/O level. Specifically what files are being accessed or written to. This could be useful to trace back missing files or folders, or figuring out the last file access a specific application did before failing.
I only recently found a tool called MobileMon v0.5 by Brian Dunn. His website, http://www.mobilmon.com/, has more information and you can download the .CAB file there.
Basically you can install and run it in the background while it logs file activity.
Once you are done you can save it to a log file. Be aware however that the file name “mobilmon.log” may be hard to open on the device itself unless you install a tool (Like Voyager or Total Commander) to rename the file to mobilmon.txt. Then you can open it with the native Word Mobile.
Memory Management and Monitoring
Another important area of concern for current Windows Mobile troubleshooting is available memory on the device. Memory leaks, multiple running applications, and garbage heaps can all attribute to doing frequent soft-reboots to get a device functional again. A little known fact that I wasn’t fully aware of is that only 32 applications (actually processes) can run at the same time and each can at a maximum access 32mb of virtual memory..
An excellent resource of a virtual memory management overview is William Blanke’s article: http://www.codeproject.com/KB/mobile/VirtualMemory.aspx
In it he also has a small (12Kb) Virtual Memory tool (must register to download, the compiled .exe in included with the source code) you can run and visually see available memory (in red) for each of the 32 process slots.
Issue #1: One key thing apart from seeing how many of the slots are being used and if they are full, is finding the “device.exe” process. This process is responsible for loading up all the device drivers and William points out the potential issues if memory is low for this slot. Specific device features may simply not work.
Issue #2: Another area of concern could be applications that load up .DLL files. These can be loaded up in *any* processing slot and can be accessed by any process. This can be bad if your process or application running in the slot needs the memory and doesn’t use the particular DLL.
However William doesn’t address that in Windows Mobile 6.1 specific changes were made to better accommodate DLL files over 64Kb. These will now be loaded into specific slots higher and away from the process slots. Thus freeing up application space and reducing this potential worry. Please see more information on this 6.1 feature from Doug Boling here.
How sure if anything has/will change in Windows Mobile 6.5 as of yet. What we can look forward to is Windows Mobile 7.0 (which is based upon Windows CE 6.0) and it’s larger scale advanced memory management, explained in more detail here or here. But basically a little like Windows XP, and a limit of 32K processes and 2GB per process, compared to 32 and 32Mb per process.
Issue #3: Careful on the usage of storage cards to install or run applications from. If the device goes into hibernation or sleep mode, it could power down the storage card and render any application housed there non-functional. See more tips here.
Some older reference links on Windows Mobile memory management:
- RAM, ROM and Task Managers
- How WM 5.0 Shell Handles Low Memory Situations
- Memory Management on WM 6.x
- MSDN Webcast: Memory Management for Windows Mobile
- DumpMem Utility
If you are using a Motorola/Symbol ruggedized device you also may want to ask your Motorola rep about their “Private SDK” and a tool called the “Remote Memory Viewer”. It may also be beneficial as Raffaele Limosani states here..
Hope this article further assists in troubleshooting Windows Mobile issues you might run into!
July 10, 2008
Posted by kdutta in C#, Development, Home Screen, Interop, Windows Phone
One of my recent projects at Enterprise Mobile was creating a custom home screen (see above) for the new MotoQ9h and Blackjack II devices. The top row is the standard Windows Mobile “Icon Bar”. The second row has the clock, messaging center (SMS, Mail, Voicemail), and current profile.
At first glance, I assumed this would be a breeze. I have a powerful layout, key handling, and paint framework that I use in every project I work on, and thought that creating a home screen leveraging that would make it trivial. Sadly I was sorely mistaken. Read the rest of this entry »
July 8, 2008
Posted by kdutta in Development, Windows Phone
It’s pretty annoying to have to create a CE Setup DLL cpp and def file every time I make a new CAB. So I finally got around to creating a VC Template to handle that for me. You can download it here.
Sadly, I did not create an installer for this template.
Installation instructions (adjust your installation directory accordingly):
- Unzip the contents onto your drive.
- Copy CESetupDLL.ico, CESetupDLL.vsdir, and CESetupDLL.vsz to C:\Program Files (x86)\Microsoft Visual Studio 9.0\VC\vcprojects\smartdevice
- Copy the Scripts and Templates folders into C:\Program Files (x86)\Microsoft Visual Studio 9.0\VC\VCWizards\SmartDeviceAppWiz\CESetupDLL
- Edit CESetupDLL.vsz and edit the ABSOLUTE_PATH value to whatever you supplied in Step 3.
And that should do it! You will now find the new project template in Visual Studio under the Smart Device folder in Visual C++.
July 6, 2008
Posted by kdutta in Development, HTC, Windows Phone
When I first got my HTC Touch Diamond a while ago, one of the first things I tried to do was reverse engineer the Sensor API found in HTCSensorSDK.dll. However, anyone who has tried to reverse engineer DLL arguments knows how tedious and painful it can be to create a dummy DLL to intercept valid arguments, parse through assembly, and inspect random memory pointers. Luckily, I did discover a registry key: HKEY_LOCAL_MACHINE\Software\HTC\HTCSensor\GSensor\EventChanged which let me figure out what the general orientation of the device was; and that was good enough for what I was trying to do.
However Scott, from scottandmichelle.net, successfully reverse engineered the HTCSensorSDK.dll. This allows developers to use the g-sensor that is available on the device. Very impressive work on the part of Scott!
Anyhow, I spent a portion of today writing a managed wrapper for HTC’s Sensor API. The code includes a sample Teeter-esque type application which allows you to roll a ball around the screen. Read the rest of this entry »
Posted by kdutta in Development, Team Foundation System Build, Windows Phone
A few months ago I sent out an email describing the process of setting up the Team Foundation Build System to play nicely with Smart Device Projects. This mail included: setting up the build machine to work with Smart Device Projects, account permissions, publish location, versioning, and also a workaround to making Smart Device CAB projects buildable by TFS. I’m sure other developers have had to or will have to go through the same pains of figuring this out, so I decided to publish it a la blog. Read the rest of this entry »
June 23, 2008
Posted by dfield in Development, Security, Windows Phone
It is a well know fact that a lot of enteprise IT pros require data encryption for mobile devices. The Windows Mobile operating system has included support for the Data Protection API (DPAPI) since Windows Mobile 2003. And DPAPI forms the basis for Windows Mobile file encryption used with removable storage cards (Windows Mobile 6.0) and main memory (Windows Mobile 6.1).
DPAPI provides easy-to-use functions for encryption and decryption. A number of applications use DPAPI. The thing that makes DPAPI easy to use for developers is that they don’t have to wite all the key generation and key management code that typically goes with any encryption solution. DPAPI uses a master key that is stored in the memory of the device. When an application calls DPAPI, the same master key is used to generate symmetric keys for all encryption and decryption operations. In this way, the application does not have to generate or manage the encryption key used. For a thorough description of DPAPI see the MSDN article covering Windows Data Protection
Of course, this begs the question, “How is the master key protected?” Read the rest of this entry »
May 23, 2008
Posted by kdutta in Development
A few months ago I wrote some code that really made me appreciate the new language feature in C#: Anonymous Methods. I decided to turn it into a sample application that creates a web request to www.google.com and downloads it when you push a button… asynchronously (that means the UI does not hang while the application is downloading). Prior to C# 2.0, doing a web request and download the content asynchronously was several hundred lines of sloppy spaghetti code: you need to implement callbacks, cleanup, error handling, state maintenance, etc. A lot of developers, myself included, would “cheat” and wrap synchronous calls in a thread to fake asynchronous requests (this is not ideal for performance).
The beauty of anonymous methods is that the compiler’s syntactic sugar handles a lot of the aforementioned for the developer very elegantly in the background. Read the rest of this entry »