Beginning Tizen Development on the Gear S

Samsung Gear S

I’ve been reading about Tizen, the mobile OS co-sponsored by Samsung and Intel, for almost 2 years, but I’ve waited to begin learning Tizen development until I could obtain a commercially available device. The Gear S is the latest in Samsung’s smartwatch line (Cnet has a detailed review) and at Uncorked Studios we have a few devices on loan for a new project.

Gear S feels heavy on smaller wrists, and my teammate observed that the curved screen has screen glare in every kind of light. Our test devices do not have SIM cards, and are paired with SIMless Samsung phones used for development, so I haven’t been able to explore the more interactive features of Gear S, but that’s fine, my goal is to show how to configure the Gear S to sideload Tizen apps so we can start developing.

  1. Install the correct Tizen SDK for Wearable package. This is importantly different from the Tizen SDK (even with the Wearable SDK option installed) because it contains the documentation and tool for registering your author certificate and device certificate with Samsung.
  2. Enable USB debugging on the Gear S in Settings->Gear Info->USB Debugging. Connect the Gear to your computer.
  3. In your IDE, the bottom left pane should show your connected device. Right-click on it and choose Properties. Copy the Device Unique Identifier (DUID).
  4. Follow the steps to register your author certificate with Samsung Developer Center. For me, this meant creating a new certificate signing request (CSR) and Samsung Account. You may also choose to generate the CSR using an Android keystore.
  5. Save your author.crt when you receive the email from Samsung (be sure to check your spam folder).
  6. Request a device certificate using your new author.crt and the DUID you copied from looking at the device properties. Look for another email from Samsung with your device certificate and password. Save your new device certificate and enter the path to device-profile.xml in your certificate request form in the IDE. Be sure not to rename author.crt or device-profile.xml, the file names are important.
  7. Right-click on the connected device in the lower left pane and choose Permit to Install Applications. This copies device-profile.xml to /home/developer on the device.

That’s it, you may now write your first Tizen app and install it on the Gear S! The above steps don’t need to be done in exact order, but they do all appear to be necessary to avoid the SIGNATURE_INVALID [22] failed error when trying to install apps. Tizen is evolving rapidly, so I expect this configuration procedure will change in upcoming releases.

Tizen apps are HTML5 and JavaScript based, with support for jQuery Mobile as well as Samsung’s UI toolkit. The IDE has plenty of examples and templates which I’m finding useful for exploring.

my first demo: an apple II story

Apple II User's Group

While cleaning out my closets today, I ran into this drawing I proudly made after presenting my first work of software on Oct 25, 1994. I was an enthusiastic 13-year-old member of the Portland Apple II User’s Group, which met monthly on the Tektronix campus in Beaverton. Of course, in 1994 the Apple II was retro; the internet age was ascendant, with local dial-up available for Windows 3.1 and Power Mac. A group of dedicated enthusiasts still met in the Tek cafeteria to discuss Apple matters and swap 5.25″ floppy disks.

Through the user’s group, I discovered Pinball Construction Set. Although I had experimented with AppleSoft BASIC and written a few tiny programs, the PCS offered a drag-and-drop interface for making a pinball game, complete with custom art and wacky physics, the end product being a bootable disk that I could contribute to the user’s group library. My journal entry for the day notes that my disk was given #104 in the library, and it was named “Fester Blaster” (apparently Pinball World was a later idea). It was a seriously dull game; I’d be surprised if anyone besides myself ever played it. I recall the group banned any further contributions of pinball games to the library. But, for a few minutes, a group of adults sat down and listened while a 13-year-old girl presented a program that she designed, built and tested using software almost as old as herself. They asked questions and gave feedback. I felt safe and respected as a contributing member of the group.

Nowadays I write useful code on current hardware (can’t wait to get my Nexus 9), and still attend user’s groups in my areas of interest. From PDXWP to PDXNode to PDXGlass, I love learning what people are doing in my tech community. Thanks, Portland Apple II User’s Group, for encouraging my lifelong interest in technology and programming.

A Weekend with Google Glass

I decided to be biased against Google Glass when I first heard about its exclusivity and the early media stories about the privacy implications of wearing a head-mounted camera/screen device. I have done some work in wearable computing in the past year, and my vision of wearables is that we should be able to negotiate more disconnection from the services that fill our lives with a constant stream of data. I love the idea of using a device that discreetly alerts me about matters I should immediately know about (messages from friends, relevant events happening nearby, breaking news in my areas of interest) but doesn’t distract my attention with irrelevant spam.

Over the summer, I had coffee with Tyler Phillipi of OTG Platforms, and we talked over the state of tech in heads-up displays and other wearables. I was surprised to find my opinion changing as Tyler filled me in on the recent history of consumer-grade HUDs. The technology has been available for decades, but it’s only in the past year or two that component costs and miniaturization have made it possible to create such displays at less than a defense-contract price point. Google producing a device and an API sends a clear message that this market is open for business. Whether Glass and its descendants end up causing good or evil, I can’t say, but as a developer in the Android ecosystem, I can’t simply ignore it or refuse to engage with it. If I’m going to have an opinion about Glass, I need to become as educated as I can.

My opportunity arrived this week, as my friend Eric invited me to review his upcoming book on programming Glass. I started reading, and by the end of the day on Thursday, I ordered one. It arrived early Friday morning. I was impressed by the packaging and onboarding experience — basic gesture instructions were printed on the box and repeated in a video that played as soon as I placed Glass on my head and turned it on.

The MyGlass companion app is pretty amazing. If Glass is Bluetooth paired, MyGlass automatically configures it for wifi networks that the phone knows about. And when I’m roaming around, the app routes data from Glass over the phone’s data plan. The near-invisible UX delights me, and knowing how difficult the Bluetooth libraries can be, I’m thrilled with how the Glass team was able to implement near-transparent syncing. This is a huge improvement over other wearables I’ve tried, which wouldn’t have been able to implement such a feature due to Android framework and hardware constraints.

Anyway, on to the weekend! There were plenty of learning moments on Friday with my coworkers at Uncorked Studios. Pictures and videos were taken and shared on social media. Most people (except prescription glasses-wearers) had no problem navigating the Glass UI. It may be useful to note that we are all familiar with multitouch smartphone interfaces and other wearables such as FitBit and Pulse. After work, I took a picture every 10 seconds on my bike commute home, hoping to get enough quality shots to make into an animated GIF.

On Saturday I took a laptop stroll with my friend Arlo around the neighborhood. People on the street didn’t seem to notice Glass, but it grabbed a lot of attention in cafes and pubs. I talked to an electrical engineer who hopes to use Glass to record difficult work procedures in order to teach colleagues. I met up with some folks who are planning to use a GoPro for their upcoming trip to Thailand, and were quite intrigued by Glass. And later, over dinner with my boyfriend Brian, the woman sitting next to us at the bar jumped out of her seat and exclaimed “Ohmygosh, it’s a Google! It’s a GOOGLE!”

I’m looking forward to exploring the Mirror API, writing apps, and finding out more intriguing uses for Glass in my life. I’ve been excited about wearable computing ever since I saved my allowance to buy a calculator watch as a kid, so it’s been great to see wearables evolve from “deeply dorky and single-purpose” to “highly fashionable and functional”. I feel positively about how Glass is being promoted using visual cues from the fashion industry (stunningly pretty models, studio lighting, on-trend branding and web design), signaling that this technology is for everyone, not just geeks. It’s pretty brilliant that the much-hyped exclusivity of the Explorers program has caused each of us to pay $1500 for the privilege of advertising the Google brand on our faces for hours a day. Marketing WIN, Google.

To commemorate the changing definition of “public” and “personal” matters, I made my second selfie wearing Glass a memorial Instagram:

#grief in the time of #selfies

Moving from Google Reader to Selfoss

As a long-time active user of Google Reader, I felt the shockwave of panic when the announcement arrived that Reader would be shutting down July 1. I’ve been hearing the rumors of RSS’s inevitable demise for years now, especially since Firefox and Chrome started hiding the presence of feeds from the main UI, and I’d agree that publishing/subscription on the web is ready for innovation. I’m not aware of any current standard that completely replaces and improves upon RSS/Atom, however, so my goal is to migrate my Reader subscriptions to a similar service that’s expected to stick around for a few more years.

I evaluated some of the most popular products documented ReplaceReader and decided on the more-obscure Selfoss because of its old-school yet fresh approach to managing feeds.

What is Selfoss?

It’s an open-source application in PHP that loads and manages a set of sources and presents new/unread stories with tagging and starring. As a user, I self-host and manage my own instance of Selfoss (on an EC2 micro instance in my case).

What’s so great?

Minimalist: Selfoss displays my latest subscribed items as an expandable list of links in reverse chronological order. While I was impressed with the user interfaces of NewsBlur, Feedly, and Flipboard, they seem to emphasize “discovery” of shared/promoted content ahead of my own subscriptions, or use some metrics to determine which stories should be “most interesting” to me. I’m not really interested in having my reading experience altered by the zeitgeist; I already discover plenty of new content among Reddit, Hacker News, and various social media streams.

Responsive and Web-Based: I need to be able to sync my current reading list and unread state automatically between my computer, tablet and phone. Running a self-hosted web application like Selfoss makes this simple. I particularly like how Selfoss’s interface is responsive on my Android devices, and in its most compact version, image loading is optional (a tremendously useful feature when I’m browsing on my phone). I may try out Fever, a similar self-hosted web reader app, at some point, when support for Android WebKit browsers is released.

Open Source: Selfoss is under active development on GitHub, so I can upgrade to the very latest version whenever I want and tinker with the code to suit my preferences. There are a few more features I’d like to see (the ability to export to OPML, improvements to security and performance, more UI settings) and nothing’s stopping me from improving the product myself.

Forward-Thinking: In addition to RSS, Selfoss supports richer sources such as Twitter, Tumblr, DeviantArt, and some custom “spouts” illustrating how any type of structured time-based data can be retrieved just by adding a PHP script. And from a privacy standpoint, now that I’m no longer reading feeds through the Google ad network, it’s pleasing to see the generic “Your Region” versions of personalized ads in my news stream.

WIMM bling

WIMM One

Over the summer, I had the pleasure of doing some R&D on this clever little “smartwatch” device called the WIMM One. It runs Android (2.2 at the time I was developing, in the summer of 2012) and although it’s not quite a miniature phone, it’s much more than a watch. As someone who remembers saving my allowance to buy a calculator watch in the 1980s, I was very excited to start writing code for this decade’s version.

The One hardware is limited by form factor and design, which led to some interesting usability workarounds. There’s no radio, audio, or camera, so the first time you turn the One on, you’re directed to configure a wifi network. The 1″ x 1″ touchscreen is too small to accommodate a smartphone-like soft keyboard, so passwords have to be entered using a slider to select one character at a time. After wifi is configured, the One syncs with a web back-end for the rest of the device configuration process, including granting access to the Micro App Store. You can also pair the One with your phone as a Bluetooth device to receive SMS and call notifications.

Screen power and wifi are the main power drains for the One’s tiny battery, so the documentation makes it very clear that apps cannot expect a continuous network connection, and should anticipate a 10-second screen timeout that returns to the watchface. The wifi sync interval is a configurable parameter, ranging from 15 minutes to Never. Apps that need a network connection must register to receive the ACTION.NETWORK.AVAILABLE and ACTION.NETWORK.TAKEDOWN events using a BroadcastReceiver. Then a background service can be employed to do the network synchronization activity.

Despite the limitations, the One is fun to use. Bluetooth sync is fast — I usually received notifications on the watch before my phone buzzed. The built-in weather app is very appealing and convenient. And I really liked the watchface that showed my next calendar item as well as the time/date. The watchband was a bit uncomfortable and bulky for me to wear all day, but I usually carried the One in my purse or pocket for quick checks, even though I always had my phone nearby.

I was just borrowing the One, so I had to return it at the end of summer, but the enthusiasm for similar small-form-factor smart devices like Pebble shows that the market is ready for wearables. Trying to fit most of the capabilities of the Android OS into a 1″ x 1″ box presents quite a few design challenges, but I suspect manufacturers like WIMM who are willing to stick with an open-ish platform like Android are likely to have some longevity in this sector.

AsyncTasks, Runnables, Handlers, and Threads, oh my!

Not every Android app has to deal with multithreading, but any app that needs to contact Google, Facebook (or any other web-services API) or load data from a local database needs to consider how to properly handle method calls that are not guaranteed to terminate in any reasonable period of time. (The Android Developer’s Guide has an article on Painless Threading, which is a great starting point for understanding why threading can be important for apps with long-running operations.) While you technically can find ways of blocking the Android UI while long-running calls occur, it’s a bad practice which will cause performance issues and may lead to the unwanted ANR.

Now that we know we need to wrap our long-running method calls in some kind of background thread, the question becomes: when should we use an AsyncTask as opposed to a vanilla Thread with a Runnable? What’s a Handler all about? Who is responsible for keeping track of all these threads?

Let’s take a look at regular Threads first. Threads have been present in Java since the beginning, and they’re the most basic, straightforward way to implement a background operation in Android. This example tries to load data from an imaginary long web service call, trying again every 30 seconds if it encounters an exception:

new Thread(new Runnable() {
	public void run() {
		String myData = null;
		while (myData == null) {
			try {
				myData = longWebServiceCall();					
			} catch (Exception e) {
				// wait 30 seconds
				try {
					Thread.sleep(30000);
				} catch (InterruptedException ie) {
					// do nothing
				}
				// try again
				continue;
			}
		}
	}
}).start();

This is compact, resource-light, and should work fine in most scenarios, but there are a couple of warning signs that this might not be the best way to use threads. First, notice that there’s no reference being held to the Thread itself. If the Activity executing this code is interrupted (which can happen at any time in the app lifecycle), this thread could be left running and consuming resources, which would be unfortunate. Also notice that there’s no way of determining when the thread has completed and doing something with the data we just fetched from that long web service call! Let’s improve this example a bit, and add a Handler to do something with the data fetched by our Thread:

final Handler dataHandler = new Handler() {
	@Override
	public void handleMessage(Message msg) {
		String myData = (String) msg.obj;
		updateUI(myData);
};
		
Thread dataFetcher = new Thread(new Runnable() {
	public void run() {
		String myData = null;
		while (myData == null) {
			try {
				myData = longWebServiceCall();					
			} catch (Exception e) {
				// wait 30 seconds
				try {
					Thread.sleep(30000);
				} catch (InterruptedException ie) {
					// do nothing
				}
				// try again
				continue;
			}
			// send to our Handler
			Message msg = new Message();
			msg.obj = myData;
			versionHandler.sendMessage(msg);
		}
	}
});
dataFetcher.start();

You can use Handlers to communicate with threads in both directions, but in this trivial example we’re just taking the data received by the thread and using it to update the UI in some way. The Handler class has all kinds of nifty methods, but be sure to at least implement the handleMessage() method in order to receive messages from your Thread’s message queue!

Also notice that we gave our Thread a name. Keeping a reference to this Thread is important, so we can stop it nicely if its parent Activity pauses or quits. This can be accomplished by declaring the dataFetcher Thread as a private member of the parent Activity class, and call dataFetcher.stop() in the Activity’s onPause() method.

The above Thread/Runnable/Handler approach works great for small background tasks, but what if we may want to invoke this type of task many times, update the user on the task’s progress, or execute some code immediately before or after the main long-running call? In Android 1.5 and up, AsyncTask is available to make threading a lot easier. It comes at a cost of some additional system resources and (sensible, in my opinion) limitations. For example, AsyncTask manages its own thread pool with a maximum size of 128 threads (as of this writing). Unless you programmatically raise the limit, you’ll get an exception if you try to invoke a 129th concurrent thread. On a phone or tablet, invoking a huge number of simultaneous threads is not a very good idea from a resource standpoint, so I think AsyncTask is a great way to keep threads safe, sane, and under control. Let’s try reimplementing our trivial data-fetcher as an AsyncTask:

private class FetchDataTask extends AsyncTask {
	private Callback callback;
	
	public static interface Callback {
		public void onComplete(String myData);
	}
	
	@Override
	protected String doInBackground(Void... params) {
		if (this.isCancelled()) {
			return null;
		}
		String myData = null;
		while (myData == null) {
			try {
				myData = longWebServiceCall();					
			} catch (Exception e) {
				// wait 30 seconds
				try {
					Thread.sleep(30000);
				} catch (InterruptedException ie) {
					// do nothing
				}
				// try again
				continue;
			}
			return myData;
		}
		
		protected void onPostExecute(String result) {
			super.onPostExecute(result);
			callback.onComplete(result);
		}
	}

The AsyncTask documentation has much more detail on the meanings of the types. In our trivial example, we aren’t passing any parameters into the tasks and we aren’t incrementing any progress units, so we’re only using the last type, the Result, which is going to be a String in our case. Note that the main logic is implemented in the overridden method doInBackground(). The result of doInBackground() is passed to onPostExecute(), and we’re passing that result on to a callback which we are going to define in our main Activity. Since the Activity itself handles the callback, we can safely manipulate our UI elements on the main thread.

public class MyCoolActivity extends Activity 
		implements FetchDataTask.Callback {
	private ProgressDialog progress;
	private FetchDataTask fetchThread;
	
	// ...
	
	public void fetchData() {
		if (fetchThread.getStatus() != AsyncTask.Status.FINISHED) {
			fetchThread.cancel(true);
		}
		progress = ProgressDialog.show(getContext(), "Fetch", 
						"Fetching data...", true, false);
		fetchThread = (FetchDataTask) new FetchDataTask().execute();
	}
	
	public void onComplete(String myData) {
		if (progress.isShowing()) {
			progress.dismiss();
		}
		updateUI(myData);
	}
}

You’ll still want to make sure to clean up your threads in onPause() as described earlier, but AsyncTask can provide some convenient advantages for implementing certain long-running background tasks. The main points to remember when working with Android threads of any kind are:

  1. Don’t block the UI thread!! Analyze your code to determine where you need to wrap long-running calls in background tasks.
  2. Be sure to hang onto a reference to your threads, so you can stop them cleanly if your Activity pauses.
  3. Only access the UI on the main UI thread. Android 3.0 and above is very particular about this.

The many joys of LEGO

LEGO Planter

I have a few permanent LEGO/Duplo items around the house, including this plant stand, so it was cool to see that an architectural team took LEGO decor to a new level.

LEGO is the best toy I can think of for introducing kids to engineering and physics ideas while encouraging creativity. And of course, there’s the excellent LEGO Mindstorms robotics kit, which is a joy for programmers of all ages and skill levels. I just finished a session of teaching Robo-Pets, and it was delightful how well everyone’s pet projects came together by the end. Some of the students had worked with Mindstorms before, and some had not, but everyone was able to challenge their building and programming skills to create some really cool robots.

In my classes we use the NXT-G programming language which comes shipped with the Mindstorms kits, but I’m hearing good things about RobotC, an alternative programming language/IDE based on C which was developed at Carnegie Mellon. There’s an introduction to RobotC at next weekend’s CodeCamp, so I’ll be excited to see a real demo and find out if RobotC might be a useful platform for future projects.

Ride In Style 1.0

After many months of development and testing, I’m excited to announce that the first beta of my first Android app, Ride In Style, has been released to the App Market on behalf of Pinpoint Pickup! I’m sure there will be many more challenges to come as the app is deployed to different types of devices and exposed to different usage patterns, but I’m looking forward to discovering those challenges and building a great experience for our riders.

The basic idea of Ride In Style is to be able to quickly and easily book a swanky towncar ride using your smartphone. The first app built was for iOS, so I modeled my development after the existing iPhone app. Since this was my first time programming Android, I learned the Android APIs as well as other concepts that I hadn’t fully explored in my previous work in systems/clustered computing:

  • Using a RESTful API to build a client/server app
  • Using Java’s HTTP libraries
  • Integrating Google’s Maps and Search APIs
  • Building a user interface capable of handling phone orientation changes
  • Handling system resource usage appropriately for small handheld devices
  • Being a solo developer and managing my own learning/troubleshooting processes

 

Fortunately, there are so many resources on StackOverflow and across the web which I’ve been able to use to learn and guide my development. I’ll plan on sharing more of what I’m working on (with code samples!) in the near future.

Assessing Password Strength

Using strong passwords is an essential aspect of securing our identities and accounts that we access over the web. There are already several online tools available to help us score the strength of our passwords, some great examples being Password Meter and Password Strength. Now there’s a new tool which uses a tiny slideshow of images to assess the strength of a password. While this is a good idea (using a quick, uncomplicated visual cue to help encourage users to choose better passwords), the execution makes me frown: it’s named Naked Password, and as the user types a more complex password, a pixelated female character progressively removes articles of clothing. Classy.

Maybe I’m just being too sensitive? Is this a good way to promote a new web tool and encourage participation in the web programming community?

Professional Identity

I’ve been a software professional since 1998, although most of my work has been behind the scenes at companies such as Tektronix, Intel, VERITAS and Hewlett-Packard. I’m currently taking a sabbatical after most recently working as a senior support engineer at ScaleOut Software. It’s been noted that there seems to be a dearth of female software developers in the community, so I started this site in order to “increment the counter” and to share code samples, articles, and thoughts that have helped me grow as a professional. I plan to keep this space focused on software-related topics.

Currently I’m working on a couple of exciting Android apps, and I hope to become more involved in the open-source community in the near future. Please feel free to follow me on twitter at @electrozoic!