Google Chromecast

I have a Blu-ray/DVD player from Samsung, and it works fine for playing dvds or blu-ray disks.  Additionally, it has a few apps, like Netflix, to play videos over the internet.  Unfortunately, using this blu-ray player to watch anything on the internet is *not* a good experience.

• It is very hard to search for a movie, because there isn't a keyboard.  You have to use the remote and direction arrows to type in a movie title. 
• Just opening the app for Netflix or Youtube is very slow (much slower than on my computer that uses the same internet connection).  
• You cannot view an arbitrary website.  You can only view videos from a few specific sources.
• For Netflix, there isn't a way to turn on subtitles.  This feature is available on my computer and tablet.

Because of this poor experience, I wanted to buy a cable to connect my laptop to my television.  After a bit of research, I eventually decided to forego wires and go for a Google Chromecast.  So far the experience has been great.  Also, every issue I had with the "Smart" blu-ray player was solved with the Chromecast. 

• Searching for movies is simple, because I use my computer to browse.  
• Opening apps is fast, because I use my computer. 
• As long as you can open a video from a browser, you can "Cast" it to the television.  So, you don't have to wait for a new app to be supported.
• For Netflix, you can turn on subtitles.

Another benefit of using a Google Chromecast is that you can cast movies from any device.  It works from my Macbook Air, my wife's Windows laptop, my Android phone and tablet.

*Update* I have had mixed results watching videos through the browser.  Perhaps the download rate isn't good enough, but sometimes the video is laggy and jumpy.  For apps, the video quality is consistently very good.

*Update* One disadvantage of using Chromecast is that you need some wi-fi infrastructure.  So, if all you have is a movie on a computer without wifi, you wouldn't be able to cast it to a television.  In a more common scenario, if you are in a hotel, the wifi restrictions may prevent you from casting videos, but I haven't verified this.

Into the unknown with Google App Engine

As mentioned before, I am setting up a cloud back-end for my mobile app.

This has involved writing code in a few different languages.  

• Java - for the android application.
• Python - for writing the Google Endpoints API.
• Javascript/Html/Css - for writing a web client for the endpoints API. 

Working from the tutorials, I have been able to progress without too much issue.  However, I ran into a little bit of confusion when trying to pass around a datetime object.  Specifically, I wanted to:

1. Start with a date / time value. 
2. Pass that to my endpoints api. 
3. Store it in the Google App Engine datastore.

I couldn't find solid documentation on how this works, so it took me a while to figure out. Here are the steps:

1. In javascript code pass in your date time for some field like so:
   { some_field : "2011-12-16T10:00:00.000" }
   The format is Year-Month-Date"T"Hour:Minute:Second.FractionalSeconds
   When I tested, passing in a time zone offset threw an error.
2. In python, when you construct your date time field use:
   from protorpc import message_types
   some_field = message_types.DateTimeField(1, required = True)
   # This is a little bit different from passing other fields which use protorpc.messages
3. Once you have the datetime field, you can use the type ndb.DateTimeProperty in your model that you will insert.

This all works by passing in a string, which gets parsed and converted to a datetime object.  If you didn't want to use protorpc conversion to a datetime object, you can pass in a datetime string that you'd have to encode and decode.

Update - After I set up an Android client to send data to my endpoints api, I got more errors about the datetime having a bad timezone format.  After some trial and error then googling for solutions, I decided that dealing with datetime data wasn't worth the hassle.  I changed the datastore to only save "Long" values.  Then I updated the API to send and receive long values.  Finally, when I get to the UI, I convert the long into date time format for display.  This made things much simpler and cleaner.

Mobile App + Cloud Backend

I wanted to set up a cloud back end for my Android application for a few reasons:

• To practice and learn about cloud and web development.
• To improve my Android app by backing up user data and to provide additional analysis based on a more full history for a given user and aggregated data from multiple users.

As a beginner web programmer, I didn't know where to begin.  Despite some criticisms, I turned to Google Cloud Endpoints in Python to provide a solution.  This works with Google App Engine and gives you a bunch of things: such as user authentication, data storage, ways to generate libraries for different clients (such as Android or the web) and scalability (although my user base is pretty small for now).

I started with this sample tictactoe application.  After a few minutes I got the sample application to work on my local machine.  When I moved the application to the cloud as a Google App Engine application, I got errors about "Origin mismatch".  The resolution was to make sure you registered any clients with the correct url.  This includes matching the protocol type as well - ie use "https".

After a few hours (spread out over a few weeks) I was able to create some new request/response objects which are used in the messages passed to and from the back end to a client.  I think I have a decent feel for how things work. In my head, the cloud back end goes through the following steps.

1. A Web Client (or Android) creates JSON (or java) message object. 
2. Your generated backend libraries convert these message objects into some request object.
3. The request object is then sent to one of your backend apis/methods.
4. (In my case) I take the request object and put it into the Google App Engine datastore.  In your case, you can do whatever you want.
5. A response message is created and sent back to the original web or mobile client.
6. Your generated backend libraries convert the response message back into a message. 
7. Your client can then do whatever they want with the response.

I haven't actually implemented or tested anything in the Android client, so we'll see if my thinking about how this all changes. 

Improving jury duty

I have an idea for improving jury duty.

Every trial should be recorded, without the jury being present.  After the trial is over, the recording can be edited. Then, the edited video can be presented to the jury who would make a decision.

Here are the advantages:

• It would save time for jurors.  An edited trial can be watched faster than the actual trial.  Any delays in the trial, such as lawyer objections, can be removed from the video.
• It would help with jury selection.  If jury selection occurred after a trial was complete and edited, they would know exactly how many hours the trial took.  
• It would make the trial more unbiased.  If one lawyer or witness makes a statement that the judge wants to 'strike from the record' and the jury is supposed to disregard it - the video can actually ensure that the jury will be presented only with what they are supposed to see and hear.