The latest version of PVR Panel, the app that lets you manage your recordings on the go, should be available shortly in the Google Play Store (if not already), as well as in the App Store later this week or early next week. As announced earlier, an update to the Videotron website caused the application to not login successfully. This has now been fixed along with other minor issues.

---

La dernière version de PVR Panel, l’application qui vous permet de gérer vos enregistrements lorsque vous vous déplacez, devrait être disponible bientôt dans le Google Play Store (si ce n’est déjà le cas), ainsi que dans l’App Store plus tard cette semaine ou au début de la semaine prochaine. Comme annoncé précédemment, une mise à jour sur le site Web de Vidéotron causé échec de l’application. Cela a été corrigé avec d’autres problèmes mineurs.

• App Store
• Play Store

read more

The latest version of PVR Panel, the app that lets you manage your recordings on the go, is available now in the Goole Play Store. This is the first Android release of the application. This version has also been submitted to the App Store for review and should soon be available there as well. This is a minor update version of iOS to fix some issues with manual recording and unlimited internet.

• App Store
• Play Store

read more

We have been a little quiet recently, but by no means have we stopped working on PVR Panel. With the recent news about iOS7 and ever increasing market share of Android, we have been hard at work to redesign the application from the ground up. So what news do we have?

• Version 1.1.2 Just got approved and it fixes an issue with some accounts where PVR terminals always reported as not PVR capable.
• Working on Version 2.0
  • Completely redesign user interface
  • Support for iOS and Android
  • Improved recording and terminal handling
  • Ability to sort each recording list according to name, time, or default order
  • Recordings now show what channel they were recorded on.
  • Other improvements

Here are some screenshots for you read more

In order to have a fully regression tested application, it is necessary to have an automated build process to ensure all checkins are validated nightly ( or whatever your schedule is). This is a simple task for most Java projects, however you may run into some issues with Android that I point out here.

• If you started your project from Eclipse, you may not have the Ant build file and supporting properties file in your project
• If you want to sign your application with a key, the default build keeps prompting you for the keystore password

Both of these are relatively easy to over come and here is a great article on StackOverflow. My only goal here is capture it all in one place.

Environment Setup

The first thing to do, is to make sure that your android SDK folder is on your path. In order to do that, just update your local .bash_profile in your home folder to include the following paths:

#!/bin/sh

export PATH=$PATH:$HOME:$HOME/Documents/Development/android-sdk-macosx/tools:\
$HOME/Documents/Development/android-sdk-macosx/platform-tools

export ANDROID_HOME=/Users/Kouroche/Documents/Development/android-sdk-macosx

Note the \ in the first export command. It is there to split the command over two lines, but you don’t need that in there. This will not only add the Android SDK to your path, but also define ANDROID_HOME which is used by the build file (more on that later).

At this point, you will either have to logout and login again, or source .bash_profile to make sure the changes took effect. To verify, run the following command from your home folder:

$ android list targets

Build files

In order to add the build files to your project, you can either create a new project from the command line and copy those build files to your project, or you could update you project from the command line to add in the build files.

Creating a new project

In order to create a new project from the command line, run the following command:

$ android create project --target  --name MyFirstApp \
--path /MyApp --activity MainActivity \
--package com.acme.myapp

The app name nor the package matter. The only thing you may want to match to your current application is the <target-id>.

Once the project is created, copy over the following files to the root of your own project and then delete this app folder.

• ant.properties – This is where you store your project specific properties for Ant
• build.xml – This is the generic build file provided by the Android SDK and will most likely not need changing
• local.properties – This file contains the path to your SDK, but I prefer not to copy it over since it may get checked in by mistake.
• progaurd-project.txt – This file contains ProGaurd rules if you choose to obfuscate your code, and more can be found here about that.
• project.properties – This file contains the target for your project and is most likely already part of your project.

Updating your existing project

This is probably your best bet since it is less of a hack and should add the same set of files to your project.

$ android update project --name  --target  \
--path 

Once again, make sure to use the same <target-id>

Customizing the build

Now that you can use Ant to build your project, you may want to customize the build process to meet your needs. For example, I always include a build ID somewhere in the application so users can report which build they are on when reporting issues, or you may want your release build to point to a different backend server than your debug build. In any case, the Android SDK makes this also very easy. Looking at the build file, it optionally imports a custom_rules.xml file that you can create in your project root folder to hook into the build process. The build file even lists out the targets for your to include. Here is a sample one I created:

What this does, is to update the build ID in my constants class, and also update the backend server my app talks to depending on whether it is a release build or not.

Signing the app

One of the issues I mentioned early on, for the need to have build automation, was having to provide a password each time the app needed to be signed. Well, the key to solving this problem is the ant.properties file which includes your project specific properties. Unfortunately, i have not found a way around having to include your password in plaintext in some form or fashion so that it can be used, but if your an individual or have a designated build person or machine, you can lock the file down pretty good. So, to get back to the issue at hand, include the following four lines in your ant.properties file and you are good to go:

 key.store=
 key.store.password=
 key.alias=
 key.alias.password=

If you have been building with Eclipse for while and don’t recall your keystore alias, an easy way is to go through the export process in Eclipse to release the app and see what the keystore alias is.

The build command

OK, so now that it is all set, the easy part is building the application. You can run either of the following commands to build the app for debug or release respectively.

$ ant debug
or
$ ant release

Good luck. read more

I found this on stack overflow, so I am just recapturing here since i found it so useful. First, unzip the APK and extract the file /META-INF/ANDROID_.RSA (this file may also be CERT.RSA, but there should only be one .RSA file). Then issue this command:

     keytool -printcert -file ANDROID_.RSA

You will get certificate fingerprints like this:

     MD5:  B3:4F:BE:07:AA:78:24:DC:CA:92:36:FF:AE:8C:17:DB
     SHA1: 16:59:E7:E3:0C:AA:7A:0D:F2:0D:05:20:12:A8:85:0B:32:C5:4F:68
     Signature algorithm name: SHA1withRSA

Then use the keytool again to print out all the aliases of your signing keystore:

     keytool -list -keystore my-signing-key.keystore

You will get a list of aliases and their certificate fingerprint:

     android_key, Jan 23, 2010, PrivateKeyEntry,
     Certificate fingerprint (MD5): B3:4F:BE:07:AA:78:24:DC:CA:92:36:FF:AE:8C:17:DB

Voila! we can now determined the apk has been signed with this keystore, and with the alias ‘android_key’. Keytool is part of Java, so make sure your PATH has Java installation dir in it. read more

There are two more players that are trying to enter the mobile OS space: Firefox, and Ubuntu. While the latter is making the move for more native applications to run faster on phones, the former is trying to take page out of WebOS’ playbook by going the pure HTML5 route. I had a chance to install the Firefox OS recently on a Nexus S and it fairs well but still has a long way to go before it is ready for prime time. Here are some links to get you started if you want to try them.

1. Take a backup of your phone.  Since i had a Google Phone, I was not worried too much since Google provides the factory images here (so long as you know your model).
2. Go to the Firefox link here and get started.

Firefox’s instructions are pretty straight forward and everything has been automated to the point that I just fast paced through the commands and ran those (on a Mac).  the process does take sometime, specially if you do not have a fast PC, and it downloads the Android SDK and tools to boot.  My only issue was finding the google page to restore my phone since the Firefox OS is still not on par with iOS or even Android, and I needed my phone. Ubuntu on the other has is making more calculated decisions and only providing installers for mutli-core devices. As they say, “You only get one chance to make a first impression,” so it better be good.  Here are some instructions to install it on the Nexus 7. read more

If you read many of the blogs out there, there are lots of people bashing the iPad mini for its lower resolution screen. This is primarily Apple’s own fault for spoiling us with Retina displays on everything, but there is a good reason for it. Since the mini was (suppose to be) a top secret project with no pre announcements and no developers having time to fine tune their apps for it, Apple made the only possible right decision. Bring the mini into market with a resolution that it already has so there is no need to update any of the iPad apps. This is one of the many faults that the Android system has and I applaud Apple for doing the right thing here. While the technology may exist to fit the iPad’s retina display pixels in the iPad mini, it most certainly would not have come in at the price point that the iPad mini did. Here is another way of looking at this: Given that the iPad mini has the same resolution as the iPad2, its smaller screen size provides a much sharper experience than iPad2. What Apple did short us on was the processor however. Granted that it could not throw in the A6X since that would have obliterated the iPad market share, but at least the A5X? The only possible reason for this is to also be able to sell the iPad2 which I do not understand now that the iPad mini is out. Long term though, I think the strategy will be that the old iPad and the updated iPad mini will have the same processor (A6X for next year), while the new iPad will have the latest and greatest (A7X?) As for the resolution, I don’t know! It must get a bump, but does that mean that Apple will introduce yet another aspect ratio for developers to code against? We will have to wait and see next year. As a final point for you to ponder, did Apple just collapse all its product announcements to the September-October time frame? I sure hope they don’t have a newer new new iPad in April. read more

Apple announced their iOS6, along with OSX Mountain Lion, and bunch of new hardware on Monday. Amongst the new features announced were features that already exist on over platforms but now they do on Apple’s platform as well. Take do not disturb for example! This feature is nothing new, and platforms like BlackBerry have had it for years, so what makes it awesome on iOS? The smart thing that Apple has done is that instead of bombarding folks with a ton of new features that will never get learnt (and thus used), they slowly introduce them so that users’ expertise grows with the platform. Its true that Android lets you configure anything and everything, but half the folks that own an Android phone don’t know how to use half of its features. They are just happy either because they know they are not sandboxed or that they do not have an iPhone like everyone else. Apple created the original iPhone with just the bare functionality needed to make it usable. Granted the whole iPhone design was new, awesome, game changing, and infinitely intuitive, but the actual functionality of the phone was nothing new. This let buys get used to the platform and grows with it as new features came out. So while ‘Do Not Disturb’ is a welcomed addition to iOS6, its not an earth shattering feature….and since its one of only a dozen visible changes to the platform, most anyone who needed the feature will know how to use it. read more

One part of testing an Android app is installing it on an actual phone and making sure that it still behaves as you expect. Given the fact that there are so many different vendors that tweak the OS in order to create a unique experience for their end users before shipping it off with their custom screen resolution phone, there is a lot that can go wrong with an android app. TechCrunch recently had an article about how a hong Kong based company tests their apps and it was a scary realization. Back to our point here! Once you have the app ready, you may want to send it to a customer or another friend to validate and chances are that they do not have and Android development environment setup to compile your code and push it to the device, so here are two other ways: (Note: the instructions here are geared towards linux based systems. Adjust as necessary for Windows)

The some-what technical way

1. Install the Android SDK. For the sake of this example we will assume it is installed in ~/AndroidSDK. (Note: For Windows you may need to installed the USB drivers as well)
2. Make sure that USB storage is turned off. This is typically off by default and you can get to the screen once you have connected you phone to your PC via USB. Swipe down from the top of the screen (just like you do to see your notifications) and choose the USB Connected option.
3. Make sure that you can install apps from unknown sources. To do this, go to ‘Settings’, click ‘Security’ and make sure ‘Unknown sources’ is checked.
4. Now open a terminal (or command) window and run the following commands to make sure that the SDk can see your device.

   > cd ~/AndroidSDK/platform-tools
   > ./adb devices
   List of devices attached 
   XXXXXXXX5B3900XX	device
               

5. Now run the following commands to install your .apk file. For the sake of this example, our file is located at ~/dev/myApp/bin/myApp.apk.

   cd ~/AndroidSDK/platform-tools
   ./adb install ~/dev/myApp/bin/myApp.apk
               

   You can optionally provide a -s parameter to install the app on the SD card.
6. You should now see the app in the list of your installed apps

The really easy way

For folks that are not technical, there is an easier way.

1. Go to the Google Play store and install AppInstaller (free app).
2. Copy the .apk file to the SD card of your phone. this can be done in two ways:
   1. If your phone has an SD card that can be taken out, you can insert the SD card into your PC and copy the file
   2. If your phone does not have an insertable SD card (like the Nexus S), then connect your phone to your PC via USB, turn on USB storage, copy the .apk file to your phone’s SD card and disconnect the phone
3. Run the AppInstaller app
4. The app will list all the apk files on your SD card. Select your .apk file to install it
Note: In this case, you may still have to check the option to be able to install apps from ‘Unknown sources’

read more

As part of the Nokia keynote at MWC, it was announced that WP7 will have lower hardware requirements to allow for cheaper phones, but is that a good move? While Microsoft is promising the keep fragmentation down, developers now have to do more testing and will have less of a potential WP7 market if their apps do not work on the lower end devices. This very thing still plagues Android and was part of the poor user experience with the older Windows Mobile phones. Sure they will run WP7 but most likely very slowly with lots of response lag. With all the subsidies that are provided, I, personally, do not see a good reason for this beyond a quick and dirty way for Microsoft to get more market share. But if it comes at the expense of the user experience, then it will be a grave mistake. Nokia has already announced the Lumia 610 with this lowered specs, and by the time you have read this article, they will probably have announced its successor. read more