[Download Code]
In a special holiday post my gift to you is not one, not 2, but 3 windows phone camera tricks. It’s a mobile ménage à trois.
1,,) Flashlight
There are lots of those flashlight apps in the marketplace that take about 2 minutes to build. This also took 2 minutes to build but it’s way better because it uses the real light on your phone. (Note: It’s turning on camera recording, but not actually saving anything when it’s done. Not sure what that will do to memory usage if you wonder through a cave with this as your flashlight. Might need to turn it off occasionally)
2) Barcode Scanning
Uses zxing. There was a Silverlight port linked somewhere that I used. Seems to work well for QR codes. Not so well for other stuff. The code in there right now should just work. You can use zxing generator to test it out. I’d like to get the 1D barcode scanning to work, but I didn’t have time to see what’s the problem right now.
3) Augmented Reality
Uses the awesome SLARToolkit by René Schulte. Basically his hello world augmented reality app running on the phone. You can use this marker to test it out.
You should just be able to run the xap in the debug folder to try all of this out. The code is all pretty simple, but a few people have asked about barcode scanning and AR so this should get you started.
If you want to build yourself you need to do a few things since I put the Microsoft.Phone.Media.Extended dll in the GAC.
1. Copy Microsoft.Phone.Media.Extended.dll to C:Program Files (x86)Reference AssembliesMicrosoftFrameworkSilverlightv4.0ProfileWindowsPhone
2. Open C:Program Files (x86)Reference AssembliesMicrosoftFrameworkSilverlightv4.0ProfileWindowsPhoneRedistList FrameworkList.xml and add the line
3. Open a visual studio command prompt and go to C:Program Files (x86)Reference AssembliesMicrosoftFrameworkSilverlightv4.0ProfileWindowsPhone and type “sn -Vr Microsoft.Phone.Media.Extended dll”
Obviously you’ll need a copy of the Microsoft.Phone.Media.Extended dll. You can get that from the rom on your phone or from a rom that someone else dumped.
If you want to build your own app using the camera, make sure to add to the capabilities in the manifest.
Also I think I contractual obligated to say this, but using the camera in this manner will not pass marketplace certification unless you also include a healthy bribe with your xap.
,
permalink
[download code]
WP7 has a several built in launchers, but the map app does not have one. It’s unfortunate because I think it’s fairly common that you’d want to have a link to get directions in a mobile app since you are, you know, mobile. Right now the best way to do that is to basically recreate the map app inside your app using Bing/Google maps to get turn by turn directions and the SL Bing maps control. There is one other alternative I found:
var task = new WebBrowserTask();
task.URL = “maps:1%20N%20Franklin%2060606″;
or
//task.URL = “maps:37.788153%2C-122.440162″;
task.Show();
That sort of approximates the behavior of the map launcher in the native apps like IE. The downside to this is that it requires 2 back button presses to get back to your app. It also inserts that page into the IE app history. It’s not ideal, but neither is trying to recreate the map app inside your own map app. I wouldn’t really recommend this approach, but it’s there if you really need it.
Extra credit:
Try playing around with the search/web tasks to see what kinds of other hidden launcher functionality you can find.
,
permalink
Maybe most people knew this, but I didn’t – WP7 devices can only have a total of 15 apps registered for push notifications per device. If the user installs 15 apps that use push notifications and your app is the 16th one installed, you’ll get a InvalidOperationException(Channel quota exceeded).
The important thing here is to just handle this and alert the user that they should uninstall one of the other less cool apps that is using up a valuable push notification slot.
This sucks though, right? I get that it’s v1 and there are limits, but 15 seems a little low especially considering how Live tiles are heavily touted in WP7 marketing. Is this widely known? Do devs handle this error and alert the user? If people are complaining about push notifications not working in your app are you aware this could be the issue?
My primary complaint is how the OS handles the user experience. No where does it tell the user how many apps are using push notifications and there is no central place to disable notifications for applications to free up a slot. Plus the certification guidelines only require that apps allow turning on / off toasts, not live tiles. So basically if an app is using a live tile, you need to uninstall it to free up a notification channel once you have 15 apps using them? It seems like there needs to be an API to see what other apps are installed so you can alert the user like “I see you’ve got two weather apps installed that use push notifications. How about you do me a favor and uninstall one of them so I can spam you with toast messages please. kthxbai” I suppose the response is that a,,) most people don’t use more than 15 apps with push notifications b) you can update tiles without push notifications and c) there aren’t even 15 apps in the marketplace with push notifications
,
permalink
[Download Code]
Scrolling is problem one of the biggest performance pain points for windows phone 7 development. I complain about it a ton (sorry phone team). Specifically for longer lists that involve images. Even a simple list of images with text can make scrolling really, really sluggish. Some of the issues are probably on my code, but I also think the runtime could use some performance enhancements. David Anson posted some good code around using a image downloader to offload work to a background thread. The major issue is that images are downloaded on the UI thread which is also the thread handling your touch input & rendering.
As you can imagine, the phone’s limited CPU can’t keep running at 60fps with all that going on. The image downloader helps, but you can optimize it further. In a list, you can avoid downloading images while the list is scrolling. You can also clear the queue and not bother to download images that you are quickly scrolling past. You can also sleep/throttle the downloads to lessen the impact on the UI thread. One thing you lose through the downloader is caching. You can cache in memory or to iso storage. Caching the bitmap source in memory makes future retrieval really fast. Just make sure you limit the cache size so you don’t exceed the 90MB limit for apps.
The long list selector also helps scrolling a lot even for flat list that don’t need the the selector functionality. (It also adds header / footer support while maintaining virtualization which is nice if you need a “get more” button at the bottom or to scroll the pano item title with the list) The long list selector uses it’s own virtualization which avoids some issues that listbox/vsp has. It also seems to have visually smoother scrolling (Touch seems a little flakey in places though – doesn’t always stop immediately and sometime drops the first flick when it’s not scrolling. Once you get it going though, it scrolls pretty smooth). Another big bonus is being able to adjust the buffer size. Normally listboxes with virtualizing stack panel buffer 3 screens. If you pan through a page then end in a flick you will use up most of the buffer which seems to cause that flash of no content. The LLS helps you work around this behavior based on your list needs. Finally it has simple events for detecting scrolling start/stop so you can adjust when you do work like downloading images.
So based on David’s image downloader / twitter sample, I made some changes and switched to the long list selector.
- Images are cached in memory after they are fetched for faster retrieval in the future.
- The background thread pauses while scrolling to avoid calling back to the UI thread and disrupting performance
- Images are not downloaded while scrolling. They get queued and only ones that are in the on screen buffer get added to the request queue. Pending requests outside the buffer are cleared.
- I just avoid downloading images until you are stopping to look at a screen. You could make some tweaks to just keep fetching until every image is downloaded, but I prefer to have the phone not do more work than is absolutely necessary
- I use a custom control in the list item which is somewhat debatable. I like to think that cutting out some binding and not parsing a template is slightly faster than the alternative. it’s a little hard to test without a profiler though.
I tried some other techniques to further minimize how much is downloaded like only fetching ones in the actual viewport. The code to actually find what is in the viewport causes more harm than good because of the amount of time it takes to calculate the bounding boxes even if you use a binary search on the visual children of the list. There is a method in the LLS to get items in the viewport, but that does not give you the containers to find the items to load images for. I also experimented with caching stuff to iso storage. I’ll post another one later when I get a chance.
So tryout the code. I think long list selector is a good replacement for most listboxes. Just keep in mind that like most code i post, it’s just a quick prototype I hacked together from some other various code and it’s not tested thoroughly. Use it to get some ideas, but you will need to do some work on your own to make sure it’s production ready.
,
permalink
[download code]
A few people asked about binary serialization in my last post. Here is a small sample app that shows how to do it. It also shows you the difference between the different serializers you can use: binary, Json.net, DataContract and DataContractJson.
You really have to run it on the phone to see the the difference. The emulator is so much faster that the results are fairly close unless you have a ton of objects.
This is mostly focused around persisting data to isolated storage for caching. Since most apps load it on startup and write on shutdown, it needs to be reasonable fast. The differences might vary a bit depending on the # of objects and the complexity of the object graph, but binary serialization is going to be way faster almost every time. Even serializing settings to a file is faster than using isolated storage application settings (for that test i took into account the time it takes to actually grab an instance of the settings otherwise the time to pull a setting out will basically be 0ms. I only did 5 strings, but if you have a lot more or try to put non primitive data types in there, the speed difference will be even more dramatic)
Regarding the binary serialization, you can just look at the code. I have some helper extensions in there. The main points to keep in mind are:
- You have to read / write in the same order otherwise you will have some unexpected values or junk objects coming back.
- To write a list out, just make sure you write the count first so you know how many loops to read through.
- If you are writing out an object, you can just write a bool if null or not first, then write the object out
- For strings you should either always write “” or just write a bool then string if you want nullable ones
- Be really careful with versioning. You should write the version number first and then run different serialization paths based on the file version if you need to add / remove properties later
In summary:
,
permalink
