Jan.10

JavaScript Grid Framework Released

tl;dr: I’ve release a new JavaScript based grid framework that will work with an ASP.Net back end. You can find the code on Github.

Several months ago I wrote a post about JavaScript based grids.  I’ve slowly been acquiring more JavaScript knowledge and have really liked the speed that you get from doing more programming that’s “closer to the metal”. I’ve found that while .Net web forms can be great for productivity, they can be bad for performance if you’re not super careful.

I had a very large, data-heavy, page with 5+ grids on it. I had done things the “typical” web forms way with Microsoft’s AJAX Control Toolkit and Update Panels. Between the additional JavaScript files that the toolkit generates for you (increasing HTTP requests) and the update panels still sending more data than necessary, my app wasn’t performing very well at all.

So when I needed to speed up  the interactions with the grids, my instinct was to turn to a very basic HTML and JavaScript approach. The result was the framework I outlined in this post. I know there are JavaScript frameworks that allow for data binding. However, some environments are really difficult to introduce new technology so sometimes you just have to work with what you have.

I’ve now put the source code up on Github here. I created a simple Visual Studio project with the bare-bones framework. Currently, in order for the project to work, you’d need to wire it up to a data source and make sure your grid configuration matched your data. I’ll look at adding that and a working sample soon.

While the framework works well, I’m not 100% happy with how it’s designed. I have some changes I’d like to make to make it more useful and less cumbersome So if you have a good idea for improving something, please send me a pull request!

Uncategorized

Dec.30

Samsung Galaxy Tab 3 Review

Shortly before Christmas, I purchased an early Christmas present to myself – a Samsung Galaxy Tab 3 7″ tablet. Now that I’ve used it for several weeks, here’s my impression of it. No, Samsung didn’t pay me to write this. I just wanted to write up my personal experiences with it.

I purchased this tablet for two reasons. First, it was a good price – it was $50 through Sprint (with a contract) and Sprint had a sale on their mobile data plans. So I was able to get 2GB of data for $15 per month. Second, I needed a real Android device to continue building my Android app (you can read more about that here). It turns out that Google licenses Google Play to each device manufacturer. So Google Play is not available on any of the emulators and if you wanted to authenticate with the account associated with Google Play, you can’t do that with an emulator.

PROs

  • Size: I really like the 7″ size for it’s mobility. It’s super easy to drop it into a back and take it with you.
  • Mobile Data: It’s nice to have 4G mobile data where you go.
  • Memory: This particular model came with 16 GB of built in memory. If you were to buy a Tab 3 elsewhere, I’ve only ever seen 8 GB models. (Yes, I know you can expand it with a SD card – it’s just nice not to have to deal with that up front).
  • Build: As with most Samsung devices, the build quality is great.

CONs

  • Size: Yes, I know I already called this out as a good thing, but the size can hinder you because once the keyboard is open, you only see a very small portion of the screen due to the overall size of the screen. I recommend that you purchase a Bluetooth keyboard if you plan to use it as a productivity device.
  • Camera: The camera is pathetic! 3 MP in the rear facing camera and 1.3 MP in the front facing camera. Granted, I don’t plan to use the tablet as a camera but it would have been nice to have a decent camera available if I need it.
  • Speed: It has a dual core processor in it (1.2 GHz). However, with a few apps, I’ve experienced a bit of stutter or lag. But for the price, it runs most apps OK.

Case

I felt that the tablet was a bit slippery when you would hold it with out a case. So after doing some research I settled on a case i-Blason on Amazon. It comes with a Bluetooth keyboard that is magnetically attached to the case. I really liked this for two reasons. First, when using the Bluetooth keyboard the on-screen keyboard is not visible. So you see much more of the screen when you are using the Bluetooth keyboard. Second, you can remove the keyboard form the case to a more comfortable position if necessary.

The case is well made – I don’t think it’s real leather but it has a nice feel and solid construction. It has a kickstand that allows you to prop the tablet up while you are using the keyboard.

There are a couple of negatives about the case but they aren’t huge ones. First, the strap that keeps the case closed should have been magnetic or velcro. It’s a bit difficult to close the case sometimes. Second, if the app has a button in a corner of the screen, it can be difficult to tab it because of the material that holds the tablet in place.

The keyboard works sufficiently. It’s very small so if you must touch-type, it’s not for you. However, if you are ok using one or two fingers to type, it’s fine and I think, faster than the on-screen keyboard. On my keyboard several of the keys don’t do what I thought they would so. For example, the apostrophe is typed using the FN key + L key which is labeled as the [ symbol. But it seems to restricted to the apostrophe. It was frustrating at first but once I learn the difference, it doesn’t slow me down.

I do recommend that if you are looking at a case (especially if you want a Bluetooth keyboard) you include this one on your list. For the price, I think it’s worth it, especially if you want to use the tablet for email, longer-form writing, etc.

Reviews

Dec.14

Building an Android App: Twilio Integration in Azure Mobile Services

This is a continuation of a series documenting my challenge to build and release an Android app. You can read the past updates here.

Over the last several posts, I’ve written about several issues around integrating Twilio into an Android app. In my latest post I wrote that I’ll be trying to use Windows Azure mobile services because it really fits the bill for what I need my Android app’s back-end service to do.

Azure Mobile Services (AMS) gives you data storage capabilities and allows you to define custom scripts or APIs. These scripts are written in JavaScript, specifically Node.js. This means you can use the Node Package Manager (NPM) to integrate libraries into your scripts much like you would use NuGet (in ASP.NET). Scott Guthrie mentioned that in the future these custom APIs will be able to be written in .Net as well.

To get started, create your mobile service in the Azure dashboard.
CreateNewServiceOnce your mobile service is created, enable source control. This will create a Git repository. With that you can use write your custom APIs (scripts) on your local machine and use NPM to add libraries to your project. Then you can push your changes up to your mobile service.
TurnOnSourceControlI used the Twilio library for Node.js. You’ll see it referenced like this:

var twilio = require('twilio');

Sending SMS Messages

This API (script) can be used to send text messages through Twilio:

exports.get = function(request, response) {
    var twilio = require('twilio');
    var client = new twilio.RestClient('AccountSID', 'AuthToken');

    client.sendSms({
        to:'[+13135555555]', //Notice the +1 prefix (required by Twilio)
        from:'[+13135555556]',
        body:'ahoy hoy! Testing Twilio and node.js'
    }, function(error, message) {

        // The "error" variable will contain error information, if any.
        // If the request was successful, this value will be "false"
        if (!error) {

            console.log('Success! The SID for this SMS message is: ' + message.sid);
            console.log('Message sent on: ' + message.dateCreated);
            //simple response to the caller
            response.send(statusCodes.OK, { message : 'Success! The SID for this SMS message is: ' + message.sid });
        }
        else {
            //These error log entries show up in mobile services log in the Azure dashboard.
            console.log('Oops! There was an error.');
            response.send(statusCodes.OK, { message : 'Error!' });
        }
    });

};

Notice only the exports.get function is setup. If I wanted to access this script via a post, then I would need to place the code in the exports.post function.

Voice Calls

exports.get = function(request, response) {
    var twilio = require('twilio'); //The NPM module.
    var client = new twilio.RestClient('AccountSID', 'AuthToken');

    client.makeCall({
        to:'+15555555', //The number you're trying to call; note the +1 prefix.
        from: '+15555555', //The number you're calling form (i.e. your Twilio number)
        url: 'https://yourMobileServiceName.azure-mobile.net/api/ApiName' //The URL that will serve your TWIML up to Twilio.        
    }, function(err, responseData) {

        console.log(responseData.from); 
    });

    response.send(statusCodes.OK, { message : 'Message Sent' });
};

Mobile App Specifics

In order to allow your mobile application to talk to your Twilio account, you’ll need to have an API that you can use to generate a Capability Token. You’ll pass this token to Twilio along with your account credentials to enable your app to make or receive phone calls or text messages.

I used another Node library to help me do generate the token. There are probably other options but I used twilio-client-token. Here’s the script:

exports.get = function(request, response) {
    var TwilioCapability = require('twilio-client-token');

    var accountSid = 'xxx';
    var authToken  = 'xxx';
    var appSid     = 'xxx'; 
    //App SID is defined when you create your TWIML app in the Twilio dashboard.

   var tc = new TwilioCapability(accountSid, authToken);

    tc.allowClientOutgoing(appSid);

    var token = tc.generate();

    response.send(statusCodes.OK, { token : token });
};

A Word about Security

Each script (API) has it’s own security settings that dicate how it can be called. By default, Azure will set up each script to be executed only when the invoker (the client) has the application key.APIDefaultSecurity

But you can also enable only authenticated users to run the scripts or only administrators to delete or patch scripts.

OptionalAPISecurityMake sure that your scripts are properly locked down! It would be a shame to get a huge Twilio bill because someone figured out how to hijack your back-end service!

Mobile,Mobile App Challenge

Dec.05

Building an Android App: Minutia

You’ve probably noticed that this week there hasn’t been a post each day. The reason is that as I’ve ramped up learning to build Android apps, I’ve less time for daily writing. So I’m going to adjust my writing schedule a bit. I plan to write at least three days per week – probably Tuesday, Thursday and Saturday.

Wow, so much has happened since last posted! I started learning how to build Android apps almost entirely from scratch. I knew that to write an Android app, you would be using Java and that’s about the extent of my knowledge. Since starting, I’ve investigated a number of tools and approaches. Here’s a recap of what I’ve found and completed so far. I’ve been in a spike mode, just trying to familiarize myself with the libraries and techniques.

Authentication

I knew I wanted to allow the user to log in with their Google account since, if you have an Android device, you’ll have a Google account. You’ll need to understand the oAuth protocol, at the very least on a high level, to accomplish that. You also must have a physical Android device handy for testing since Google Play is not on virtual devices (AVDs).

Twilio

I was able to configure a basic Twilio integration with a test Android application and back-end. As I outlined in this post, you’ll need to have a server than can generate a capability token (at least to do it the right way). I found that my test credentials for Twilio would allow me to call my Twilio app. I know you couldn’t call real phone numbers with your test credentials but I guess they consider your app a real phone number.

Security

One of the issues that I’ve run into is how to keep my communication with my back-end server secure. The oAuth call to Google happens over HTTPS. However, unless I have an SSL certificate for my back-end site, my communication between by app and back-end is not secure (i.e. encrypted), specifically when I pass the users access token to the back-end. One of my limitations for this project is that I’m very cash constrained so I’m trying to make the cash that I do have for the project go as far as I can. As I started to research my options, I wasn’t keen on any that I found. I didn’t want to go the route of a self-signed certificate and the hosting providers (that I have/looked at) that offer SSL certificates generally, aren’t cheap and require that you buy a certificate from them.

Eureka!

As I was researching, I found Azure Mobile Services. They have a free tier offering so I figured it wouldn’t hurt to check it out. What sold me on Mobile Services is that they have Twilio integration, Google account authentication (among a number of providers) and I don’t have to maintain a server or even a website in the traditional since. Also, they offer support to just about any mobile platform on the market today (Android, iOS, Windows 8, etc).

So basically, I don’t have to roll my own Google account authentication – I can’t introduce any bugs or weaknesses. As for Twilio, all I should have to do is translate my logic from my web application prototype to the Mobile Services scripts. The scripts are in JavaScript so that’s a win in two ways: first, I know the language but second, Twilio offers a JavaScript client library. As I build out a solution in Mobile Services, I’ll post more details with code examples.

Wow!

Have you ever worked on a project that made it feel as if your head was going to explode from all that you needed to take in? That’s were I’ve been for the past week but not that I’m complaining mind you. It actually feels good to stretch your grey matter from time to time.

Programming,Mobile,Mobile App Challenge

Dec.03

Building an Android App: Twilio Capability Tokens

One of the things that I’ve noticed while working on my app, is that the documentation is very sparse sometimes. Usually, you can find raw SDK documentation for classes and methods, but finding quality code samples can be hard. So to help remedy that here’s how you use capability tokens with Android, C# and Twilio.

Twilio’s mobile app clients are designed to work with a back end server unlike a web app where all of the Twilio integration code could be in same app. The capability tokens help ensure that your Twilio credentials are not compromised by the app inspection process. Here’s how it works.

First, create a Twiml App in your Twilio dashboard. The app is really just a collection of URLs to your backend that Twilio will call when you invoke your app.

Second, configure your backend server to generate your capability token. This is straight forward with the only thing you may need to tweak being the client capabilities. You can find more about the capabilities here. If you are using a WebForm page, be sure to remove all of the template HTML. That way only the token is returned to the mobile app. Also, make sure you have an SSL certificate so that these tokens won’t be vulnerable to man-in-the-middle attacks!

var accountSid = "Your Twilio Account";
var appSid = "Your Twilio App ID";
var authToken = "Your Secret Twilio Auth Token";

//Generate the capability token based on the account sid and auth token.
var capability = new TwilioCapability(accountSid, authToken);
//Set the mobile apps permissions
capability.AllowClientIncoming("MyAndroidApp");
capability.AllowClientOutgoing(appSid);
var token = capability.GenerateToken();
//Return the capability token to the mobile app.
Response.Write(token);

Third, configure your mobile app (in this case Android) to request and accept a capability token from the back-end server. This example is based off Twilio’s Hello Monkey sample app.

public class MonkeyPhone implements Twilio.InitListener
{
    private static final String TAG = "MonkeyPhone";

    private Device device;

    public MonkeyPhone(Context context)
    {
        Twilio.initialize(context, this /* Twilio.InitListener */);
    }

    /* Twilio.InitListener method */
    @Override
    public void onInitialized()
    {
        Log.d(TAG, "Twilio SDK is ready");

        try {
            String capabilityToken = HttpHelper.httpGet("http://myBackEndSite.com/GiveMeACapabilityToken.aspx");

            //Create callbacks to act on various points of the call life cycle.
            DeviceListener deviceListener = new DeviceListener(){

				@Override
				public void onPresenceChanged(Device arg0, PresenceEvent arg1) {
					// TODO Auto-generated method stub
					
				}

				@Override
				public void onStartListening(Device arg0) {
					// TODO Auto-generated method stub
					
				}

				@Override
				public void onStopListening(Device arg0) {
					// TODO Auto-generated method stub
					
				}

				@Override
				public void onStopListening(Device arg0, int arg1, String arg2) {
					// TODO Auto-generated method stub
					
				}

				@Override
				public boolean receivePresenceEvents(Device arg0) {
					// TODO Auto-generated method stub
					return false;
				}
            	
            	
            };

            //Create our device object with the capability token.
            device = Twilio.createDevice(capabilityToken, deviceListener);
            
            
            //Add callbacks for points in the connection life cycle.
            ConnectionListener connectionListener = new ConnectionListener(){

				@Override
				public void onConnected(Connection arg0) {
					Log.d(TAG, "Connected");
					
				}

				@Override
				public void onConnecting(Connection arg0) {
					Log.d(TAG, "Connecting");
					
				}

				@Override
				public void onDisconnected(Connection arg0) {
					Log.d(TAG, "Disconnected");
					
				}

				@Override
				public void onDisconnected(Connection arg0, int arg1,
						String arg2) {
					Log.d(TAG, "Disconnected");
					
				}
            	
            };

            //Pass in the parameters and connect.
            Map params = new HashMap(1);
            params.put("PhoneNumber", "+15555551234");
            device.connect(params, connectionListener);
            
            device.listen();

        } catch (Exception e) {
            Log.e(TAG, "Failed to obtain capability token: " + e.getLocalizedMessage());
        }
    }

    /* Twilio.InitListener method */
    @Override
    public void onError(Exception e)
    {
        Log.e(TAG, "Twilio SDK couldn't start: " + e.getLocalizedMessage());
    }

    @Override
    protected void finalize()
    {
        if (device != null)
            device.release();
    }
}

This is the basic syntax. Currently I’m having some problems with the sound support on the emulator that I was testing one. I’ll run this on a real Android device soon. As a general rule, it’s always best to have an physical device to test on. The emulators don’t have every features, specifically the Google Play Store which you could use for authentication in your app. This is because the Play store is licensed to individual device manufacturers and thus not available on that virtual device that you just created.

Updates to this code will happen soon!

Programming,Mobile,Mobile App Challenge

Dec.01

Building an Andriod app: Back End and Twilio

Yesterday, I described the challenge that I had laid out for my self to build an Android app in six months. I’ve actually been working on the project for several days basically spiking out different features to learn how it’s all going to work. Two areas in particular, the back end and Twilio integration. I like to do a bit of research before jumping in head-first because it helps me see the big picture before I get wrapped up in the details. Here’s some of the things that I’ve discovered and learned so far.

Twilio Integration

My current protoype, in the form of a web application, uses Twilio for messaging capabilities and I need to port that functionality over to the mobile application. However, all of the Twilio functionality is all in one place in the web application. When you want to add Twilio to a mobile application, it requires that you have some functionality in the mobile side and other functionality in a back end somewhere.

From Twilio’s website; Mobile Architecture with Twilio

I had started this project thinking that, like a web application, all of the Twilio integration would be in one place. Since that’s not the case, I’ll have to plan on a more robust back end for my Android application then I had planned on. Basically, most of the Twilio integration will be in the back end but with a little bit in the mobile application.

The code to retrieve the capability token as mentioned in the above image looks like this:

TwilioCapabilityTokenNotice that there must be  a way for the client (the mobile app) to authenticate to the back end. I know this is obvious but it creates another question of what’s the best way to handle the authentication.

Authentication

After doing some researched, I think I’ve settled on using oAuth. Google supports this so that should my make task easier (at least I would think!). So my plan is to use oAuth to have the user authenticate in the app. Once the user is authorized, I plan to send an authorization token to the back end over SSL (to avoid man-in-the-middle vulnerabilities). Once the back end receives that token, it will know to generate the Twilio capability token and proceed with the user’s desired action.

From what I’m reading, it looks like once the user is authenticated, I can store their user id or some sort of token in a Shared Preference so they don’t have to log in again. When they return the app, you can check to see if their token is there. If so, they continue into the application. Otherwise, they’ll be directed to authenticate again.

Thoughts?

As I’ve mentioned before, this is all new ground with me. If you have any suggestions or think I’m headed down the wrong road, let me know!

Programming,Mobile,Mobile App Challenge

Nov.30

My Mobile App Challenge

I’ve recently been exploring how to build an Android app. I’ve written several posts on tooling and other basics of Android development. Now I’m ready to start building my own Android app to be eventually released in the app store. I want to throw down the gauntlet for myself by writing this post and declaring my goals.

The Challenge

Build a working Android application in six months (June 1, 2014) based off my current prototype web application, submit it to the app store and have it approved for sale. Along the way provide bi-weekly update blog posts on the application’s progress.

Why

I have several reasons for doing this and doing it this way.

  • I’ve been a professional web developer for about six years and I would like to broaden my skills beyond only the ASP.NET web stack.
  • I have an idea that I’ve tried in the form of a web application but I believe it would be better suited to the mobile market.
  • I wanted to announce and keep track of my project publicly because, like promising to blog daily, it helps to keep you motivated and on track.

Why Android

I’m sure this question will be asked and the answer is quite simple. In order to compile iOS apps, you need a Mac or you need to rent a Mac through a service like vmOSX. I currently don’t have one and don’t want to shell out the money quite yet. I’ll be looking at iOS in the near future but I wanted to start this now. I’ve learned that if you wait for perfect alignment on all fronts, you’ll be waiting for a long time. It’s better to go!

Tooling

I’ve settled on using the version of Eclipse that Google provides on the Android developer site. I like it because the tools are free but I will have to dust off my Java skills in addition to learning the Android framework. That’s not a bad thing though. Learning something new keeps you from falling into a rut. I liked the Xamarin tools but I’m trying to avoid that cost.

Time Frame

I chose six months because I want my goal to be measurable but yet realistic. I have family and church commitments that take up time each week. I believe that I can build an app within six months despite those limitations.

Daily Blogging

I’ve enjoyed blogging since I made the commitment to write everyday – really more than I thought I would. I don’t know how this challenge will affect that pace. If my writing schedule changes, I’ll post it here.

Programming,Mobile,Mobile App Challenge

Nov.29

Easy Steps to Poor Leadership

Just a short post today but I’d like to point to you a resource that I found interesting and helpful.

I was recently listening to Michael Hyatt’s podcast ‘This is Your Life’, specifically episode 74. The topic was: How to Frustrate Those You Lead (Are You Making These 13 Mistakes?).

If you’ve not listened to the podcast, go listen! His podcast is quickly becoming one of my favorites in my RSS reader.

Here are the 13 ways to frustrate those you lead:

  1. Don’t be responsive.
  2. Cancel meetings at the last minute.
  3. Reprimand team members in front of their peers.
  4. Change your mind frequently.
  5. Be vague with expectations.
  6. Always ask for things that weren’t requested.
  7. Focus on superficial rather than substantive.
  8. Assign work and then micro-manage it.
  9. Do all the talking.
  10. Never recognize team members for good work yet raise their standards.
  11. Always catch them doing something wrong.
  12. Communicate that you are the fount of all knowledge.
  13. Be moody.

If you want to be a good leader, simply invert each item and seek to achieve that. Good leadership requires hard work. It seems that it’s easy to identify bad leaders and to talk about what makes a leader good but it’s much harder to actually be a good leader.

There were many additions supplied by other listeners in the comments. Check it out!

Musings,Business

Nov.28

Happy Thanksgiving All!

Here in the US it’s Thanksgiving day so no technical post for today. Rather, I’d like to reflect on being thankful.

I’m thankful for a God that loves and cares for me.
I’m thankful for a beautiful wife.
I’m thankful for my wonderful children.
I’m thankful for my family and friends.
I’m thankful for a roof over my head and clothes on my back.
I’m thankful for my job and the income it provides.

I believe it’s important to be thankful. It’s easy to become un-thankful and disregard blessings as they come our way. I read a quote today in an email from Rob Hatch:

“Adults don’t learn by doing, they learn by reflecting on what they have done.” –John Dewey

So, please, take time today to reflect on your blessings before you get caught up in the shopping and bustle. I know this, if you stop and reflect long enough, you’ll find that you’re very blessed! The more you stop and reflect, the less you’ll be focused on others and what’s going on around you.

Musings

Nov.27

Building an Android App: Tools

This is the third article in a series on building mobile apps, specifically Android. You can read part one here and two here. You’ll notice that I changed the title of the series to reflect a change in tooling which I discuss below.


Today I’d like to briefly take a detour from the technical process of building an app and talk about the developer tools that are available to build mobile apps.

Xamarin

If you’ve been following the last several blog posts, you’ll know that I’ve been playing with the Xamarin tools, Xamarin Studio in particular. I really like Xamarin’s offering because I can utilize my C# skills and familiarity with the .Net framework to build both Android and iOS apps. I’m still in the trial period of Studio so when that ends I’ll have two choices. I can let it revert to the starter edition or I can pay for the Indie license.

The starter edition is fine but has some limitations such as compiled app size (no more that 32k) and no third party dependencies. If you’re writing a real world app to do work, I think you’ll hit that limit pretty fast.

The Indie edition removes those two restrictions. You do still have to use Xamarin Studio but in my experience with it, that’s not too bad. I believe some features of Studio are restricted to the business edition or higher. However, the Indie edition sells for $299 per platform per developer. So if you are a solo developer who wants to use Xamarin to build for both Android and iOS, you’ll have to purchase licenses for both platforms. They did tell me that they give a ten percent discount for both but it’s still $538. And if you would want Windows phone, I think that would be yet more cost. As much as I like Xamarin’s tools so far, I simply can’t shell out that kind of money at the drop of a hat.

An additional cost is that if you wish to build iOS apps, you’ll need a Mac to compile the app on. Xamarin honors Apple’s requirement that iOS apps be built on their OS (and I can understand) but if you don’t have a Mac or access to one, you’ll need to buy one.

Android Studio

I found Android studio referenced on Google’s developer documentation site. Android Studio is based upon IntelliJ IDEA. Of course, you’ll be writing Java code but honestly, there isn’t a huge leap between C# and Java. So that doesn’t bother me too much. The actual IDE interface does appear to be a bit more complex or offer more features, depending on how you look at it.

Eclipse with ADT

Google provides a version of Eclipse with Android Development Tools (ADT) built in. Eclipse is a well know and solid IDE that can be used for many different languages and platforms. So it’s no surprise to me that you can use it for Android development. The nice thing about this option is that if you are familiar with Eclipse, you’ll feel right at home with little transition.

What about iOS?

To my knowledge you have several options to build iOS apps. You can use the Apple provided Xcode or Xamarin or or JetBrain’s AppCode IDE. However, as far as I know, you’ll still need a Mac or access to one to build your apps using these tools.

My focus with this series will be on Android apps because of the lower barrier to start and learn.

Programming,Mobile