The League of Paul

MahApps.Twitter library for Windows Phone 7 (WIP)

Paul — Thu, 02 Sep 2010 00:00:22 +0000

Eventually there will be MahTweets for Windows Phone 7 (WP7), but for now I’m concentrating on getting the base library done. One of the advantages is with anything .NET is that you can reuse code from platform to platform – ie, the same C# that works on desktop can work on the web via ASP.NET or in games on the Xbox 360. Kinda. The problem is the compact/minimal variants such as Silverlight or WP7’s Silverlight don’t cover 100% of the “desktop” .NET or don’t work with third party libraries, or the Client Profile which lacks certain core libraries (such as System.Web). In this case, being Silverlight, everything has to be asynchronous, and is Silverlight 3 based, rather than the current release of Silverlight 4.

Currently there is no real error checking/handling, nor any tests, but the basics work. MahApps.Twitter makes use of JSON.NET (for deserialisation) and Hammock (for OAuth and REST requesting)

Eventually this library will also come in a desktop flavour, it’s just a matter of time.

You can grab the full code on Codeplex, released under the MS-PL. At this stage there is no binary release.

Example Usage

Obviously, make sure YOURKEY, YOURSECRET and YOURREDIRECTURL are changed. This is example code for SetupView.xaml.cs – an PhoneApplicationPage. You will need a webbrowser to do the initial OAuth authorisation dance. I don’t have XAuth to test against, and I also believe it defeats the purpose of OAuth in the first place, so it isn’t currently covered by the library. If you wish to contribute something XAuthey, comment below or contact me via Codeplex :)

private const string ConsumerKey = "YOURKEY";
private const string ConsumerSecret = "YOURSECRET";
private TwitterClient t;
public SetupView()
{
    InitializeComponent();

    t = new TwitterClient(ConsumerKey, ConsumerSecret);
    t.BeginGetRequestUrl(RequestUrlCallback);
}

public void RequestUrlCallback(RestRequest request, RestResponse response, String Url)
{
    wbBrowser.Navigate(new Uri(Url));
}

private void wbBrowser_Navigated(object sender, System.Windows.Navigation.NavigationEventArgs e)
{
    //If it contains mahtweets.com, it is redirecting.
    if (e.Uri.AbsoluteUri.Contains("YOURREDIRECTURL"))
    {
        t.BeginGetAccessToken(e.Uri,AccessTokensCallback);
    }
}

public void AccessTokensCallback(RestRequest request, RestResponse response, Credentials Tokens)
{
    //STORE THESE TOKENS!
    t.SetOAuthToken(Tokens);

    //Get information about the authorised user
    //t.Account.BeginVerifyCredentials(VerifyCredentialsCallback);
}

public void VerifyCredentialsCallback(RestRequest request, RestResponse response, ITwitterResponse Response)
{
    User u = ((User) Response);

    //Do cross thread GUI shit for WP7/SL/WPF and you could do Application.Name = u.Name
}

‘

MediaScout: Now sans Paul

Paul — Mon, 16 Aug 2010 04:33:39 +0000

One of my first C#/OSS projects was TVScout, which eventually was renamed to MediaScout. Once it had a sufficient level of functionality, I grew disinterested with the project and ended up abandoning it. Krishmav has taken over as the project lead – I’ve stepped down. There is no bad blood here, just somebody interested in picking up where I left off. I am a little sad that none of my icons or artwork are in use anymore, but c’est la vie.

The last version I was involved with was v0.9c, while the new version is now errr version 3 Preview 2. Since I was running it all on my Windows Home Server, I’m unable to use the newer versions (requires Windows 7), so I’ll be sticking with my old versions for now.

MediaScout is available from Codeplex, in both source and binary form.

Twitter User Streams

Paul — Tue, 03 Aug 2010 01:02:00 +0000

Twitter has for awhile had streaming support for larger volume of Tweets, usually processed by companies offering analytics or searching or other ‘services’ that need a high volume to make stuff work. Streaming maintains a very long HTTP session (infinitely long?), where Twitter pushes the data to you. In the case of "firehose" or "gardenhose", they’re all public Tweets, sometimes filtered to keywords, etc.

Another analogy is the long car trip with kids in the back. The standard RESTful API is the children asking "Are we there yet? Are we there yet? Are we there yet?", whereas Streaming is the parents in the front saying "I’ll tell you when we are there…. we’re there"

From Twitter’s point of view, at least in theory, this will result in less requests so their servers will be hammered less and in turn could result in a faster, more reliable service. From the user point of view it gives you real time Tweets using less traffic. Its win-win.

What are user streams?

When they had their first conference earlier in the year (Chirp), they talked about something called user streams. Are they a stream of a single user? No, user streams are what all desktop clients will eventually move to. They’re a stream of the logged in users friends tweets, mentions and direct messages as well as what I presume will be called "stream events" which include interactions between two people and optionally a Tweet.

You’ll notice the Streaming API is read only, so the REST API will be hanging around for writing (Tweeting). Infact, REST API will be hanging around so that you can do the initial "fill up" of the client, since the stream only gives you Tweets since you connected to the service.

Sadly, it is in limited beta at the moment, so while we’ve now got the code to do it in MahTweets, we can’t freely give it out to everybody yet.

Stream Events
A stream event has a target, a source, a target object and a name for the event. So far I’ve only been able to observe the target object being a Tweet.

Target	User
Source	User
Target Object	Tweet (Optional)
Event	Favourite, Unfavourite, Follow, List_Add_Member, List_Remove_Member

This will lead to interesting things where you can see people following you in your client, perhaps as a notification (depending on client, etc).

This is the real time web.

Building Android APK’s with TeamCity

Paul — Sat, 24 Jul 2010 10:50:19 +0000

I’m slowly getting my various Android projects up to bitbucket, codeplex or another open/public DVCS and I’m slowly making sure that all of them can have auto-magic continuous integration. As my Windows Home Server is running TeamCity for MahTweets, its natural I want to keep it all contained in that.

Originally I was trying to use the Ipr build runner, as I’m currently using IntelliJ IDEA, which is picked up by TeamCity rather well except it only generates a bunch of .classes (so it is compiling) but none of the dex/APK’s required for Android.

The only solution I could find is to use Ant!

Generating the Build.Xml

When I created projects in NetBeans, Eclipse or IntelliJ, none of them created the Build.xml file for your project. Luckily the Android SDK does.

You’ll find "android" under the tools subfolder in the SDK. From a command line:

android create project –n –t –p –k –a

All values are required. As I’d already created my project, I stuck in some dummy values and just grabbed the build.xml out of that folder, and placed it into my project folder. I used:

android create project –n OhHai –t 1 –p D:\OhHai\ –k MahApps.OhHai –a OhHaiActivity

Make sure you commit the build.xml to your VCS!

BuildAgents

Your BuildAgents are going to have to have a few extra requirements – primarily the Android SDK as well as the SDK for the particular version you are building against (run the SDKSetup inside the SDK download).

Once you’ve done that, you need to add a property to your BuildAgent to point to the location of the SDK you’ve just downloaded. Edit your BuildAgent configuration (by default on Windows, its C:\BuildAgent\conf\buildAgent.properties) by adding

android.platform.base=pathToSDK

To the end of the file. This will disconnect and then reconnect your BuildAgent from your BuildServer. For me, it was

android.platform.base=D\:\\SDKs\\android-sdk-windows

You’ll notice this isn’t the path to the individual SDKs, and that’s because the ant tools build.xml calls are under /tools/lib

New Configuration

Most of the values can be configured as normal, ie, give it a name, select your VCS, trigger, dependencies etc There are only a few extra values you’ll need to throw in

General Settings
Artifact path: /bin/YourProjectName-debug.apk
Runner
1. Select Ant as the build runner
2. put build.xml as the path to your build file (unless you’ve changed the name of it)
3. put ‘debug’ as your targets (unless you want another build target)
4. Add an Additional Ant command line parameters, put in -Dsdk.dir="%android.platform.base%"
  Ant properties are passed in via the command line as –DparamName=ParamValue.

Personally, I’ve added an additional Configuration Parameter Requirement, of android.platform.base to make sure only the BuildAgents with it configured attempt to build it.

Voila, build the project (and providing it doesn’t have compile issues), your APK should be the only file in your artifacts!

WP7 v Android: Dev ‘fluff’ stuff

Paul — Fri, 23 Jul 2010 06:42:05 +0000

While I’ve outlined some of the programmatic differences between WP7 and Android, there is often a lot more to it than that – how easy is it to get the environment up and running? How easy is it to learn?

Getting the SDK/Tools up and going

WP7′s SDK can be found through developer.windowsphone.com portal (download is on the standard Microsoft downloads, but developer portal is the easiest way to grab it), you grab the 69kb web bootstrapper, which then downloads up to 339.8MB, installs the various tools and you’re right to go – from Visual Studio or Blend, you can go File –> New Project –> Select Windows Phone.

Android’s SDK is found on the developer.android.com portal, grab the appropriate version for your operation system, make sure Java 5 or 6 is installed, then once you’ve unzipped the SDK, you’ll need to run SDK Setup, which lets you choose and download which version of the SDK you’d like. Android is relatively fragmented, so you need to download the SDK for the lowest version of the API you’d like to target – that is, if you want to run on Android 1.6 and above, download 1.6 (version 4 of the API) and then you can target that/make virtual machine with 1.6 on it.

By default, the SDK Setup tool will query https://dl-ssl.google.com/android/repository/repository.xml for the latest information, but that has never worked for me on a variety of machines. You’ll need to go into the Settings for SDK Setup and tick ‘force https://… sources to be fetched using http://…’

Once you’ve got the SDK up and running, you may as well create a Virtual Device, unless you plan to do all your debugging on a device.

Finally, you’ll need to setup your IDE of choice – Eclipse has a plugin from Google with its own set of hopes to jump through, IntelliJ IDEA Ultimate ships with Android support, and NetBeans has an unofficial/unsupported plugin. And finally, now you can start a new Android project.

Winner: WP7 – set and forget, done. Android you have to earn it.

Included SDK/Tools

I should stress this is about the free SDK/Tools included, not any third party purchased tools.

WP7 includes

Visual Studio 2010 Express for Windows Phone
Expression Blend 4 Express for Windows Phone
XNA
WP7 Emulator

You cannot, however, select what components you want although thankfully its smart enough to figure out that if you’ve got VS2010 Standard or above to not install another copy of VS.

Android includes

SDK Tools
- Dalvik Debug Monitor
- Draw 9 Patch
- Android Emulator
- Android Emulator manager which lets you create different VM configurations (storage/screen res/etc)
- SDK version downloader/manager (download more versions
Eclipse Plugin

While at first glance you would be forgiven for thinking WP7 is superior as it includes a full IDE and a UI designer, there are a few caveats. The Android Dalvik Debug monitor can attach to either a VM/Emulator or a real device – meaning you get full file access/exploration, full debugger output, device querying, radio querying, ability to take screenshots from the device and more. While these tools don’t trump Visual Studio in most, having no way to query a physical (or emulated) device for WP7 or to take a screenshot is going to be very frustrating.

Not this is based on Windows Mobile/CE experience rather than WP7 experience – why? I have a Windows Mobile device, but I do not/cannot get a WP7 device just yet, unless a Microsoftie wants to donate one of the 90,000 or so Microsoft are giving away to employees.

Winner: Not clear (leans towards WP7)

Emulator/Virtual Machine

Hands down, WP7 emulator is faster. I timed my first WP7 app from cold boot to being in my application…. 7.5 seconds. That’s insanely fast. It is, however, showing it’s beta-ness. I’ve managed to crash it – which just meant it closed, no restarting, it doesn’t respond to keyboard input – which means you have to use the onscreen keyboard using your mouse.

There doesn’t seem to be a way to start up the WP7 emulator without using Visual Studio or Blend, but I may just be missing something (why would you want to do this? Well, you might want to test the horrible browser on WP7 to make sure it works with your site). This is a downside but it is fairly easy to work around considering how fast VS2010 and the emulator boot.

The Android VM is sloooow. Even on my quad core system, it 32 seconds for the OS to boot, let alone deploy and start up my app. And it’s relatively buggy too – icon’s are supposed to scale with the resolution of the VM but more often than not on my WVGA VM it doesn’t scale leaving the UI stretched or overly spaced.
On the plus side, crashing the Android VM results in the virtual device rebooting itself inside the VM instead of just closing, it also responds to full (physical) keyboard input, and has a wider variety of installed apps to interact/test with.

Winner: Not clear (leans towards Android, seriously, lack of keyboard input on WP7 bites)

Documentation

"Back in the day" JavaDocs were all the rage, but that was a long time ago. Android’s documentation is barely more than JavaDocs for Java and Android API’s available. While there are some examples, they’re not entirely useful or beyond basic "Hello World" given the complexity that Android has.

Google has Android Docs?!?!?!?! I thought those were templates for future use

Ive been working with the SDK since it has been out and the one thing i have learned is reading those docs is about as useful as trying to light a fire with a squirt gun. Its easier to go onto the github and rip apart their source to see the truth

Those are two tweets in response to when I said the Android docs weren’t that good.

On the flip side, MSDN has come a long way in terms of visual and cross browser appeal in the last few years. In general, the MSDN docs are detailed enough and generally contain a sample in C#/VB/XAML.

Winner: WP7, and by a big margin. MSDN rocks my socks.

Winner?

Again, there are no winners here – both have their positive and negative elements. I’d compare debugging but that’s a little unfair until I’ve got a WP7 device to compare against.
WP7 is easiest to get going, and has better documents, but some of the tools are lacking and the VM is a little frustrating.
Android is daunting to get going and you’re better off reading other people’s code/Android’s source code than reading the Android docs

(I’m happy to have devices donated to compare…Microsoft, same goes for you HP/Palm on WebOS, or Apple if they want to send me a Mac Mini+iPhone)

MahTweets has moved to Codeplex!

Paul — Thu, 22 Jul 2010 02:16:14 +0000

At the start of the year, Codeplex announced support for Mercurial (Hg), possibly the best tooled DVCS for Windows. We’ve now come full circle – originally MahTweets code was on Codeplex via TFS/SVNBridge, but after one too many stuff ups with SVNBridge refusing to let one or more of the team commit, we switched to self hosted SVN.

MahTweets has now returned to Codeplex ’cause DVCS is cool.

From a tooling point of view, all we had to do for Fisheye was upgrade 2.3 to get support for Hg. Changing TeamCity over was pretty easy too, like Fisheye we just had to point it to the Hg binary location and it was good to go. JIRA hooks into Fisheye, so it doesn’t need explicit Hg support. From a dev client point of view, we’ve changed from TortoiseSVN to TortoiseHg, and VisualSVN to VisualHg.

However, the solution, project and MSBuild file that the build server uses more complex. All of our automagic builds append the revision number from the source control. We were achieving this by using the MSBuild Community Tasks which includes tasks for Subversion in all our CSProjs’ (so every assembly has the correct version) and in our msbuild file.

The obvious issue with this is that no projects could build because SvnVersion had a bit of a panic attack being unable to find any Subversion bindings. While there is no Mercurial support in the MSBuild Community Tasks, there is (thankfully) a separate library available – MSBuild Mercurial Tasks.

Very similar syntax, with the only difference being no ToolPath. The SvnVersion task uses ToolPath to point to your svn.exe, whereas HgVersion just uses the “hg” command so a command line client must be installed/registered properly with Windows (TortoiseHg installs this, or they maintain a command line client without the GUI)

WinMoPho vs Android from a dev point of view

Paul — Wed, 21 Jul 2010 10:00:33 +0000

I’m a PC and I’m a big fan of WPF, so it could be assumed that I like Silverlight and therefore WinMoPhone 7. Well, the truth is I love WPF but think that Silverlight is more like WPF vPainful, and I use Android which has some fantastic hardware and is available now unlike the mythical Windows Mobile 7.

It wasn’t until the recent spat of previews coming out from places like Engadget that I was even vaguely interested in WinMoPho – seeing the simplified design of Metro on AMOLED screens looks fantastic. Some would say it lacks depth and is a bland design. In many ways I agree but as Microsoft have rather strict requirements for WinMoPho devices including OLED as a minimum (no LCD!) I’m beginning to see the beauty in it when compared to the reasonably complex (visually) Android particularly when out in the sun.

From a dev point of view, there are strengths and shortcomings for both systems, and I’m not entirely sure who is the clear winner, if there can be one.

IDEs and tools

Dev tools
Okay, so an IDE is never required, but I like to be productive and don’t memorise every namespace. Android is Java based, so naturally the top choice for IDEs are all Java based as well – the three I’ve tried are Eclipse, Netbeans and IntelliJ. Personally I think IntelliJ is the best, although it’s not free if you want to do Android development. These run on *Nix, OSX or Windows, giving you greater flexibility in your development. Eclipse is as close to the ‘official’ IDE as it gets – Google provide the plugin for it – but there is no IDE directly from Google. This is good in that you can use whatever you are comfortable in, but bad because the general tooling is pretty below par.

WinMoPho has Visual Studio 2010 Express for Windows Phone. It’s a mouthful, but personally I think its justified as its just that much better than the offerings for Android. VS10 Express is free (or you can use the professional versions of Visual Studio), but only runs on Windows which may hinder some. While it is an incredibly complex piece of software, it is also incredibly powerful.

The debugging is just.. well.. better on VS. And IntelliSense works. Eclipse’s auto-complete names all the arguments arg0, arg1 .. argN, I could never get NetBean’s debugging to actually debug and IntelliJ is case sensitive – it won’t pickup Hello for helloWorld.

Design/UI tools
The WinMoPho Developer tools “ship” with an Express version of Expression Blend (Express Expression Blend… another nice name) which will only let you do WinMoPho development. This is free, and will remain free. Eventually it’ll install into regular (non-free) versions of Blend. Blend is, without a doubt, awesome. I won’t bore you with lots of details, but it is a designery app for designing your applications UI. How designery? Blend 4 can directly import Photoshop (PSD) or Illustrator (AI) files – AI goes straight to XAML/Vectors, and PSD will try to map text layers up to Textboxes, rectangles, etc – your layer structure keeps intact!

In contrast, Android has no UI editing program, but there is an editor for Eclipse. Sadly, the editor is absolute balls – you can’t drag controls around, you can’t resize, etc. The closest to something useful is the unofficial DroidDraw java applet. I think DroidDraw is mostly limited by the poor layout system that Android has.

Multitasking

Android has it, WinMoPho doesn’t. I think it is rather stupid of Microsoft given the current mobile climate, but whatever. Android apps have multitasking built into them, even the default Google applications use the same API’s – no hidden secrets or limitations that other OS’s have/have had. There are just a few caveats to be aware of

your application could be terminated at any time if its not in the foreground, if the device start running low on memory
every time the user switches back to your application (even after it is killed), the view is recreated as it was in the onCreate method of your Activity unless you override onResume as well.
Your application should always go back to the previous Activity it was on when they left – Android handles this automatically.
You can explicitly run in the background so that Android doesn’t kill off your application if you use Services or BroadcastRecievers – think music playing app, IM, etc.

Sharing, Intents and Navigation

One thing thing that WinMoPho completely lacks is one of the greatest strong points of Android – the ability to share data between applications, but without having to specifically target an application. For example, if you take a photo then press share, any application that has registered the correct intent for sharing will appear in a list – email, a variety of Twitter clients, Flickr, Facebook, whatever, so long as its registered, it can handle it.

In Android, you register an Intent with the OS to replace pretty much anything that matches that – such as the Homescreen. That’s right, things as basic/essential as the homescreen can be replaced – how awesome is that?

In MahTunes I’ve registered the AlbumListActivity to hook up to the “Launcher” activity – this just means it’ll appear in the “app tray”, and that it should launch this activity first. Intents are registered via the AndroidManifest.xml that every Android app needs.

Navigation

Navigation in Android is through Intents whether it is between applications or inside a single application.

Intent playbackIntent = new Intent(getApplicationContext(), PlaybackActivity.class);
Track t = (Track)tadapter.getItem(arg2);
playbackIntent.putExtra("trackId", t.ID);
startActivityForResult(playbackIntent, 0);

This example is also from MahTunes, inside the track selection dialog, it creates a new Intent to target the PlaybackActivity class and loads it up with some primitive data – you can only pass along primitive types, no objects.

If you’re querying another application, the Intent constructor parameters would look like

Intent intent = new Intent("com.google.zxing.client.android.SCAN");

At the other end, inside PlaybackActivity’s onCreate, it can query the intent “bundle”

long trackId = getIntent().getLongExtra("trackId", -1);

There is one downside – moving from screen to screen inside your own application in Android feels more like a collection of “activities” rather than a proper application, as you pass data around from one to another. There is the (optional) Application class to extend which acts as a global wrapper around them.

WinMoPho navigation around an application isn’t much different. It treats everything as a “page”, so you use Uris to navigate around. This has the same problem of not being able to send complex datatypes to the new page all that easily. That being said, the “application” class isn’t optional, so you’ll always have that container.

NavigationService.Navigate(new Uri("Details.xaml", UriKind.Relative));

Data binding

Android doesn’t have data binding, it’s as simple as that. You can set X to Y, but you’re essentially just setting X to be an instance of Y – when Y updates, X doesn’t. Yes this is framework magic. Data binding and data templating are the two greatest things about WPF and Silverlight.

And this leads into the next point, Lists. Lists are hard, okay? Well, okay, I’m lying, lists aren’t hard at all on most UI frameworks but this is one of the greatest downfalls of Android programming. Unless you want a very basic list of just a string-per-line, Android requires you to create a custom ListAdapter which I’ve written about before. There are a whole stack of performance issues and enhancements you need to do to each and every one of your adapters – it’s just a messy and repetitive process.

Silverlight? myListBox.ItemSource = MyList; Done. That won’t automagically setup your UI to be bound the way you want it (in fact it’ll just give you a .ToString() of each object per line), but you don’t have to write any custom code to adapt a list to your ListBox.

List example

This is a screenshot taken from the Android Dalvik Debug Monitor (part of the Android SDK) of MahTunes running on my Milestone. You’ll notice there are issues with text-wrapping and originally there were issues with some items stretching further than others. Ignoring the rounded corners on both the background item and on the album art and ignoring the custom font, how do you do this in Android and in WinMoPho?

Android

AlbumListActivity.java (snippet from where the Activity sets the current view)

AlbumAdapter albumadapter = new AlbumAdapter(this, Albums);
ListView lvMyListView = (ListView)findViewById(R.id.ListViewAlbums);
lvMyListView.setAdapter(albumadapter );

AlbumAdapter.java

package mahapps.MahTunes;
import android.content.Context;
import android.graphics.Typeface;
import android.view.LayoutInflater;
import android.view.View;
import android.view.ViewGroup;
import android.widget.*;
import java.util.*;

public class AlbumAdapter extends BaseAdapter
{
    private List elements;
    private Context c;
    public AlbumAdapter(Context c, List Albums) {
        this.elements = Albums;
        this.c = c;
    }
    public int getCount() {
        return elements.size();
    }
    public Object getItem(int position) {
        return elements.get(position);
    }
    public long getItemId(int id) {
        return id;
    }
    public void Remove(int id)
    {
        notifyDataSetChanged();
    }
    public View getView(int position, View convertView, ViewGroup parent)
    {
        LinearLayout rowLayout;
        Album t = elements.get(position);

        if (convertView == null)
        {
           rowLayout = (LinearLayout)LayoutInflater.from(c).inflate(R.layout.albumitemview, parent, false);
           TextView tv = (TextView)rowLayout.findViewById(R.id.txtName);
           tv.setText(t.getName());

           tv = (TextView)rowLayout.findViewById(R.id.txtArtist);
           tv.setText(t.getArtist());

           ImageView iv = (ImageView)rowLayout.findViewById(R.id.imgAlbumArt);
           iv.setImageBitmap(t.getAlbumArt());
        } else {
            rowLayout = (LinearLayout)convertView;

            TextView tv = (TextView)rowLayout.findViewById(R.id.txtName);
            tv.setText(t.getName());

            tv = (TextView)rowLayout.findViewById(R.id.txtArtist);
            tv.setText(t.getArtist());

            ImageView iv = (ImageView)rowLayout.findViewById(R.id.imgAlbumArt);
            iv.setImageBitmap(t.getAlbumArt());
        }
        return rowLayout;
    }
}

AlbumListView.xml

AlbumItemView.xml

WinMoPho

C#/Codebehind (snippet where the list is bound to the list of Albums)

lstMyList.ItemsSource = myListOfAlbums;

XAML/UI

There are better ways to write the XAML than this, but this is the easiest way to demonstrate it.

Android has a tonne more code, a tonne more markup (and trust me, its needed), and it still doesn’t function 100% of the way it should and you’d have to rewrite a lot of that code if you wanted to do another list of tracks instead of albums. On Android if you add to the list, you have to make sure you notify the adapter so it can update whereas its automatic on WinMoPho.

Images

If you’re getting images on Android from anywhere but local storage, you’re going to have some fun times there – by that I mean images from the internet.

Android

Part of the issue is when do you download the image? In this example I was setting it in the custom ListAdapter, but this of course creates a very slow loading of the list – you need to spin this off to a different thread.

ImageView imgAvatar = (ImageView) rowLayout.findViewById(R.id.imgAvatar);
URL aURL = null;
URLConnection con = null;

try {
    aURL = new URL(t.Avatar);
    con = aURL.openConnection();
    con.connect();
    InputStream is = null;
    is = con.getInputStream();
    BufferedInputStream bis = new BufferedInputStream(is);
    Bitmap bm = BitmapFactory.decodeStream(bis);
    imgAvatar.setImageBitmap(bm);
    is.close();
    bis.close();
} catch (MalformedURLException e) { }
catch (IOException e) { }
catch (IOException e) { }

Silverlight

There are several ways to set images – you can set the Source on an Image in XAML to the Uri, you can databind the Image’s Source in XAML to a property on the object you’re binding (can be a BitmapSource, String or Uri) or you can set it in code like Android. However, most of the time the first two options are what you’ll do, and the framework automatically takes care of loading it asynchronously. It really is that simple – its hard to stress how easy it is compared to Android.

One clever thing Android does do around images, however, is the Nine-Patch image. A NinePatch is like the name suggests, an image that can be divided into 9 sections, where the “inner” (5 if you were looking at it from a numberpad) section can be stretched for content. The editor for this is included in the Android SDK, although isn’t very friendly to use.

Persistence and Storage

WinMoPho will not give you direct access to the file system nor will it ship with (apparently its there, just not accessible) SQL CE. The only way you can store on the device is using IsolatedStorage, a concept brought over from the “desktop” version of Silverlight. That being said, Alex Yakhnin has created a LINQ Data Provider for Isolated Storage which works wonderfully by serialising objects to JSON, then storing in IsolatedStorage, which is incredibly easy to consume.

public static class Storage
{
    private static ObjectStore datastore = new ObjectStore("MahBlogMobile");
    public static ObjectContext Context = new ObjectContext("MahBlogMobile");
    public static void StoreAccounts(IEnumerable account)
    {
        datastore.Persist(account);
    }
}

Android by contrasts lets you write to the file system and comes bundled with SQLite. While it (seems?) to lack ORM’s like LINQ, it’s flexible enough to let you decide how you want to do it.

public int InsertProduct(Product P)
{
    SQLiteDatabase db = mOpenHelper.getReadableDatabase();
    db.execSQL("INSERT INTO Products ('Barcode', 'Name') VALUES ('"+P.barcode+"','"+P.name+"');");

    int id = 0;
    Cursor c = db.rawQuery("SELECT ID FROM Products WHERE Barcode='"+P.barcode+"' AND Name='"+P.name+"'",  null);
    if (c.moveToFirst())
    {
        id = c.getInt(c.getColumnIndex("ID"));

    }
    db.close();

    return id;
}

Device Resolution/Size Handling

WinMoPho will launch with WVGA (800×480) support only with HVGA (480×320) coming later on the track and only on phones (so no 10″ tablets), while Android supports FWVGA, WVGA, HVGA, FWVGA, QVGA, FWQVGA, WQVGA and various phone screen sizes and formats as well as tablets and portable media players. As such, Android has a harder time supporting all those devices, but has some clever ways to support these.

When you create a new project in any of the Android-compatible IDE’s, you’ll have a /res folder with /drawable, /drawable-hdpi, /drawable-ldpi and /drawable-mdpi inside of it. The idea is that you put your special version of your images into each folder and Android will be smart enough to know when to use each resource – ie, for your icon.png, you make it 72×72 for hdpi but mdpi is 48×48. You must declare in the manifest what screens you support, otherwise there is a good chance it’ll default to the wrong one.

While it’s great there is that level of support, the biggest issue is that the magic is based on density. According to Google, medium density is 320×480 on 3″ to 3.5″ screen OR 480×800/480×854 on 4.8″ to 5.8″ screens. Does this mean that a 5″ tablet is going to use a 48x48px icon instead of a 72x72px icon?

From a code point of view, getting the correct resource in said folders is performed in a similar magical way – R.drawable.icon refers to the correct density without having to figure that out yourself. That being said, you can do that

float scale = this.getResources().getDisplayMetrics().density;
Bitmap bdRounded = BitmapHelpers.getRoundedCornerBitmap(artwork, (int)(15 *scale), (int)(320 *scale), (int)(320 *scale));

In this instance, scale would return 1.0 on a low density screen and 1.5 on a high density screen.

What will WinMoPho require? At this stage it’s unclear what Microsoft are planning, but because Silverlight is a vector based layout system, many applications may not require changes as vectors scale rather nicely.

Winner?

I don’t think there is a clear winner – for some people Java is going to be more natural but for others its going to grate against everything they know. I think I personally need to more Android dev before I chalk it up to ‘not for me’.

WP7 clearly has some great things going for it – the .NET stack goes from web, desktop, phone, Xbox360, and various mono implementations. Android on the other hand has the flexibility that no other mobile OS offers and a very passionate developer base, with a user base starting to challenge the almighty iPhone juggernaut.

Review: Singularity (PC)

Paul — Thu, 08 Jul 2010 00:47:03 +0000

In Singularity, you play BJ Blazkowicz fighting the Nazi paranormal units, taking place in Isenstant. You gain super powers when you find the Thule medallion which lets you slow down time..wait wait wait wait – thats Wolfenstein, not Singularity, although you wouldn’t be blamed for confusing the two. Both games are from Raven Software (the studio who gave us wonders like HeXen, Heretic, Soldier of Fortune (1 & 2), Jedi Knight Outcast and even XMen Legends), both feature historical weaponry/settings, both feature special powers, and both had a somewhat frustrating upgrade system to the devices that gave you the special powers.

In Singularity, you play Nate Renko who is thrown between modern day and 1955 on the elusive and fictional Russian island, Katorga-12. Kotorga-12 is the only known source of Element99, which in turn gives the scientists there the ability to manipulate time. The Time Manipulation Device (TMD) is the main draw card for Singularity – it acts as a gravity gun, shield and weapon. I will say this, while Singularity is better than Wolfenstein, neither are stand out games. While Wolfenstein just lacked punch and was overall too repetitive, Singularity‘s main draw is the TMD – but in reality, that was its only draw, as the game overall feels like yet another generic shooter.

The game is short – only taking four or five hours to stomp through, the enemies are either mutated creatures which can teleport (but due to somewhat dumb AI never bother doing that to get the advantage on you) or Russian soldiers (either Cold War era or modern) who are happy enough to line up and die in an orderly fashion. The weapons the enemy have are no match for the arsenal you can get – such as a time manipulating sniper rifle, a rail gun, or a gun which slows time so much you can actually steer the bullet. While these sound fun at first, combined with the overpowered TMD, the game just becomes boring – a game isn’t fun if it doesn’t challenge you on some level. That isn’t to say there aren’t genuine moments of "zomg that was so cool" when you first get the weaponry, but those moments were spread so thin throughout the game.

Once interesting tidbit is that this Raven game doesn’t use any of iD’s Tech engines, but instead uses Unreal Engine 3. During the peak of the id Tech 3 based games, Raven produced four hugely successful games, not to mention paved a lot of the way with a string of hits using the id Tech 2 engine. Heck, Raven even created (the somewhat lacklustre) Quake 4 – that’s saying something about how involved they’ve been with iD tech over the years. Now, this isn’t their first Unreal Engine 3 based game (X-Men Origins: Wolverine was), but it still came as a bit of a surprise to me. Despite years of working with iD Tech, Raven are relatively new with UE, and it shows – it suffers a hilarious bug where textures just stop loading (or take 10-20mins to load). This is a feature of UE3, where textures stream in to create a smoother loading experience, rather than loading all at once and slowing down the system.

(Image source: IGN)

As you can see from the above image the gun is fantastically detailed but the rest of the game looks terrible. More often than not, while playing Singularity, I was faced with this problem. Apparently there are now workarounds, and Raven are looking into it but it is somewhat of a big flaw.

Review: Prince of Persia (2008, Xbox360)

Paul — Wed, 07 Jul 2010 02:29:28 +0000

To distinguish this game from the previous Prince of Persias, Ubisoft decided to not give it a subtitle like the Sands series (Sands of Time, Warrior Within, Two Thrones, Forgotten Sands). The name also bares little resemblance to the game itself – the "Prince" isn’t actually a prince – it is hard not to dislike the game when it is setup to deceive you before you even begin! Ubisoft somewhat gave up after that and it is rather hard to list any distinguishing features that the game has. If I was pressed, the celshaded graphics are the only unique element in the series although not particularly unheard of these days.

Unlike the Sands series, Prince of Persia features a different protagonist, a different story, and fairly different gameplay. I think it is probably important to note the rating that this Prince gets – and I mean from classification boards – PG (Parental Guidance recommended) compared to previous games which generally got M (Mature Audiences). By targeting kids, most aspects of the game have been cut back to make it easier.

So how is the gameplay different and easier? Well, for a start there is no death – if you die, the other character will magically teleport and rescue you. Combat is also missing in action – or at least as good as gone, as the occasional combat comes down to Y, X, X, RT looping until the opponent is dead. Well, dead or decides to run off, as you seem to kill very few bad guys. And finally, a staple of the Prince of Persia series is missing (at least in the half of the game I’ve completed so far) – there are no traps. The game boils down to random/repetitive/unsatisfying combat, jumping with terrible lighting and camera angles so non-death is more often than not, collecting ‘light seeds’ and not much else.

The story focuses on Elika the princess – your NPC companion – and Ahriman – the evil god of evilness. He’s been set loose, its your job to seal him back by making Elika heal the ‘fertile grounds’. As mentioned, whenever you are near death in combat or because you’re plummeting towards the ground, Elika will teleport and save you. Wait, hang on, the princess has magical powers that allow her to teleport (even when she’s caged up) to save you, she heals the lands, and is actually a princess, while you’re a nobody with no powers – why are you needed? While Elika can teleport, use magic in combat, heal the lands, and run circles around you there is one thing she needs you for – climbing on mossy walls. Yes, as soon as you hit a mossy wall, the character freezes as he waits for Elika to climb on his back.

Overall, I only have this game because a friend saw it going cheap ($10) at JB HiFi. If you don’t treat it like a Prince of Persia game or if you’ve never played Sands of Time, you might enjoy it but otherwise it’s a pretty hard sell.

Auto ClickOnce Deploys with TeamCity + MSBuild

Paul — Thu, 24 Jun 2010 06:42:51 +0000

Currently when you go to install MahTweets, you’re greeted with this less than reassuring dialog:

Unknown publisher? Well, you should know it’s from the MahTweets team, but you can’t be certain – the next beta of MahTweets will be signed properly so a known publisher will appear (or you can be sneaky and install our nightlies auto-generated by TeamCity+MSBuild, which is what this article is all about!). Once done, you’ll see a dialog more like this:

First step is getting the verified publisher parts working. For that, I highly recommend Jeff Wilcox’s guide to Getting Started with code signing for under (USD)$100. Jeff’s guide is great, until you come up to the issue of wanting to automate the whole build process.

TeamCity

Next is TeamCity (TC) from JetBrains. If you’re new to the game, TC is one of many Continuous Integration (CI) servers, this one happens to have a free/limited version, which is perfect for small open source projects or for a personal CI. Being Java, TC runs on any platform.

MSBuild

This is the only “hard” part – partially because Mage is frustrating but mostly because MSBuild is frustrating. It was a matter of a lot of trial and error. To make things a little easier, all the build files are in a subdirectory of the root of the project creatively titled BuildOutput. Inside that there are the subfolders for the three main stages – Application (compiled output), Install (ClickOnce output) and Zip (the zipped ClickOnce output).

You can download the latest version of the MahTweets msbuild script from SVN or Fisheye

Most build scripts have a few different stages to them, and ours is no different. For us, the flow is something like

Cleanup – make sure all the required build directories exist (and you could have it delete the contents first)
Version – since it is automated builds, we make sure the AssemblyInfo contains the Subversion revision number associated with this build
Compile – actually make the project to publish
Publish – this is the difficult/frustrating section, and I’ll only really go in depth about Publish.
1. Our particular Publish process deletes all the duplicated files, cleans up any PDB’s and XMLs that were compiled, and removes the .manifest and .application generated.
2. Next is the first stage of the ClickOnce files – creating the MahTweets.exe.manifest from the files created in Compile using the devil known as Mage.
3. After creating the manifest, the rest of the files are copied over into the appropriate directory (Install/Application Files/MahTweets_X_Y_Z_R/ and then their subfolders, where X is MajorVersionNumber, Y is Minor, Z is Build and R is revision) – this could be performed before or after, makes no real difference.A key thing to note here is all files are appended with “.deploy” at the end – if you’re serving up your ClickOnce files from non-IIS servers, this isn’t needed, but IIS won’t serve up files ending with DLL or Config.
4. While mage could be used for the next stage, all reports are that GenerateDeploymentManifest (part of MSBuild) is far more suited to the job. This creates the MahTweets.application file – the file that launches the ClickOnce install process.
5. Mage is called once more “update” the MahTweets.application file, but in reality all it does is sign it
Package – to be honest, for us at the moment, the package section is unnecessary, but it is nice to have around. Packaging in this case just zips up the ClickOnce install to a single compressed file.
Eventually, we could turn this into packaging up the files to do a portable build, but we’re not there just yet.

MSBuild: Publish

As I mentioned, the meat of this post is is to do with the Publish section – see the links in the above section to get our full MSBuild file if its of interest.

Looking in more detail at the section below

The ItemGroup then Delete cleans up the files generated in Compile that are duplicated – most projects shouldn’t need this, but we do some funny things around plugins
The next interesting command is the Exec calling mage – this creates the .exe.manifest file from the directory, and then signs the manifest.
Next we copy all the files (using that cryptic Copy command) and rename them to append .deploy – as mentioned above, this is related to IIS
Next GenerateDeploymentManifest creates the .application file – this is an XML file that ClickOnce gets all the details about the install from.
And finally mage signs the .application file

This general process should work for all, but there are a few flags to be aware of

As we needed MahTweets to be a 32bit app (because of some dependencies) –Processor x86 is required in the initial mage calls
In GenerateDeploymentManifest’s parameters
- MapFileExtensions=”true” lines up with renaming files to .deploy
- Platform=”x86″ sets the processor correctly
- TargetFrameworkMoniker=”.NETFramework,Version=v4.0,Profile=Client” is used because we’re targeting the .NET 4 Client Profile for increased compatibility.

 

    
    
      
      
      
      
      
      
      
      
      
      
      
      
      
      
      
    
    

    
      $(OutputInstallPath)Application Files\MahTweets_$(Major)_$(Minor)_$(Build)_$(Revision)\

Thumbprint vs file+password

You may have noticed that I’m using “CertHash” instead of the usual CertFile (and pointing to a PFX) + CertPass. The advantage with this is that its easy to take this key and distribute it so it builds on any and all machines, so long as they can get a copy of the key file. The disadvantage is, your “secret” password is visible to anybody who has access to your build server.

However, if you install the certificate on your desired machines, you can use the ‘thumbprint’ which is a hash/unique identifier to that key. Since the thumbprint is unique to that key – it’s the same value on all machines, so install the key onto the machines you want (and enter the password during installation) and nobody you don’t want having access to that password will ever be able to see it.

The downside to this is that it could still be abused – if somebody had access to TC with enough rights to create a new project or somebody committing to one of your source control repos, by just knowing that thumbprint, the could trick your machine into signing their own code under your key.

Making sure your build agent has access to your key

By default, TC Build Agents run under the LocalSystem account (on Windows) and when you install a certificate (by double clicking on it) it only installs under that account. Thankfully, Laurent Kempé figured out an easy way to install the certificate under the LocalSystem account.

You will need a tool from SysInternals called PsExec, then using PsExec:

> Psexec.exe -i -s cmd.exe

you will have ran a command prompt on your system in the Local System Account (LSA).

Using that new command prompt, cd to the folder containing your certificate and start it

> my_TemporaryKey.pfx

Then you will face the Certificate Import Wizard in which you click Next > Next > Type the password > Next.

Your certificate is installed now for Local System Account (LSA), and your build should work now.

Not using ClickOnce? No worries – sign the executable(s) instead

signtool.exe sign /f PathToKeysAndCert.Pfx /p “MySuperSecretPasswordToUseThePfxFile” /v “C:\MyFileToSign.exe”,