Making a message box in Android

Turns out that making a simple message box in Android is just complicated. So here's a very useful snippet:

public void messageBox(String title, String message) {
    AlertDialog alertDialog;
    alertDialog = new AlertDialog.Builder(MyActivity.this).create();
    alertDialog.setTitle(title);
    alertDialog.setMessage(message);
    alertDialog.setButton("OK", new DialogInterface.OnClickListener() {
        @Override
        public void onClick(DialogInterface dialog, int which) {

            dialog.cancel();

        }    
    });
    alertDialog.show();

}

Why Microsoft is going to dominate 50% of the mobile world in about 5 years

Microsoft nowadays looks like it's desperately trying to hold a grip on something. The recent acquisition of Skype, Windows Phone 7, and other things just come to show us how lost they are. They are even planning ARM support for Windows 8, something which they tried to avoid for a long time. Since the uprising power of the ARM processors, alongside the amazing power consumption, it just looks like their way out of the mud. It seems that they are decades away from Apple and Google, but they do not even realize how far ahead they are.

The Windows x86 platform is the most common operating system in the world today. Therefore, trillions of code lines in the world have been written and adjusted for this platform, and Windows 7 continues to be the primary, and probably most successful operating system today, especially in the enterprise world.

As of March 2011, more than 80% of the world's consumer devices are Windows powered - XP, Vista and 7. But how can this advantage be leveraged into the mobile world against Android and iOS? You'd obviously think that an ARM compatible, slim embedded operating system from Microsoft is the solution, and so do Microsoft. That's why Windows 8 is planned to be compatible with ARM. But the answer is much closer than anyone would expect.

The battle between ARM and Intel is emerging - ARM, from one side is trying to breach the high end CPU market, whereas Intel, using their Atom CPU are trying to compete in the mobile market. But up to now, Intel's new System-on-Chip - code named Silvermont, using their new Tri-gate transistor technology cuts down the power consumption in half, which makes it just good enough to manufacture smart-phones. By 2013, very power efficient smart-phones will be emerging with enough processing power and memory to run a fully fledged Windows 7 operating system, which is exactly what they need to leverage their advantage in the PC market. Once Windows 7 mobile phones will be available, they will start replacing desktops and laptops using docking stations and mobile modules, utilizing a mobile interface when on the go, or a normal desktop when docked. This use case is perfect for enterprise, where people need their laptops with them at all times, wherever they are, and would love saving the hassle of carrying around their laptop around.

The many users who use Android and iOS today, who still use a Windows based operating system, would prefer a Windows mobile phone, if they were good enough. But so far, Microsoft is losing this battle, and losing hard. Windows Phone 7, just like Android 2 and iOS will become obsolete, as Android 3 or Chrome OS from Google, OS X for mac and Windows 7/8 from Microsoft will take over the mobile market as well, once power efficient, small factor Atom CPUs will emerge, like Silvermont. The mobile operating systems will become history. Once this happens, the current operating system market share will start reflecting on the mobile devices, and will increase Microsoft's share to become at least 50% (and even up to 80%) of the mobile market.

The upcoming Windows 8 tablets and other mobile devices, based on ARM, which will probably start to emerge in the upcoming year is a step forward in terms of Windows 8, but the ARM support could only help Microsoft in taking over a larger share of the market. However, this is not the reason for their upcoming success - their success will emerge from the fact that Windows is the most commonly used OS today, running on the x86 platform.

Microsoft still has a long way to go. But the fact is, that their natural advantage will allow them to succeed in the mobile market, without the need to work hard, like Apple and Google. By 2016 or so, mobile platforms will be as fast as modern PCs, allowing everyone to have their handheld computer in their hands at all times, playing CPU intense computer games they recently installed, and using Outlook, Office and Visual studio at the same time.

How to root an HTC Desire using Unrevoked on a 64 bit Windows

Just recently, the "Unrevoked" one click rooting program became available from http://unrevoked.com.

The "Unrevoked" root won't run on a Windows 7 64 bit out of the box, on an HTC desire, because of a missing driver. This can be easily fixed in a few steps.

Some of you might have noticed that neither the HTC sync drivers nor the Android SDK have the "Android Bootloader Interface" drivers for a 64 bit Windows. You can't really get them either.

Luckily, the Android SDK drivers have a 64 bit version of the ABI driver. The problem is, that the USB identification of the device is unknown to the driver. To fix it, we need to add the following line to the "android_winusb.inf" file:

[Google.NTamd64]

%SingleBootLoaderInterface% = USB_Install, USB\VID_0BB4&PID_0C94&REV_0100

This line defines that on a 64 bit machine, if the USB device with a vendor ID of 0x0BB4 (HTC) and a product ID of 0x0C94 (Bootloader interface on HTC Desire), then the driver that should be installed is "%SingleBootLoaderInterface%".

After that, install the driver you altered and that's it.

This is how the USB driver identifies itself (when the driver is not installed, you can look at the hardware IDs of the device identified as "Android 1.0" (which is the bootloader interface before the driver is installed).

Just right click the driver, click Properties, go to Details, and look at the "Hardware Ids" section. You can do the same trick for any other Android device which supports ABI.

Convenient thread logging in Python

I wrote a small logging thread class for easy logging.

My standard error now looks like this:

[Fri Apr 23 15:58:20 2010] [ClipboardReader-1] Starting log...
[Fri Apr 23 15:58:20 2010] [SocksValidator-1] Starting log...
[Fri Apr 23 15:58:20 2010] [SocksChecker-1] Starting log...

Every thread also has its own logfile in the "logs" directory by his class name. I made up the thread name to add the class name of the instance (won't be LoggingThread if you inherit from it).

class LoggingThread(threading.Thread):
   def __init__(self, *args, **kwargs):
       threading.Thread.__init__(self, *args, **kwargs)
       if hasattr(self.__class__, "instance_count"):
           self.__class__.instance_count += 1
       else:
           self.__class__.instance_count = 1

       self.name = "%s-%d" % (self.__class__.__name__, self.__class__.instance_count)
      
       if not os.path.isdir("logs"):
           os.makedirs("logs")
       self.logfile = open("logs/%s.log" % self.name, "w")
       self.log("Starting log...")
      
   def log(self, data):
       logline = "[%s] [%s] %s" % (time.ctime(), self.name, data)
       print >> self.logfile, logline
       self.logfile.flush()
       print >> sys.stdout, logline

Getting and setting text from the clipboard using Python

Just name this module clipboard.py and use GetClipboardText/SetClipboardText. Very handy, and doesn't really need the win32 extentions, although it's used here.

from ctypes import *
from win32con import CF_TEXT, GHND

OpenClipboard = windll.user32.OpenClipboard
EmptyClipboard = windll.user32.EmptyClipboard
GetClipboardData = windll.user32.GetClipboardData
SetClipboardData = windll.user32.SetClipboardData
CloseClipboard = windll.user32.CloseClipboard
GlobalLock = windll.kernel32.GlobalLock
GlobalAlloc = windll.kernel32.GlobalAlloc
GlobalUnlock = windll.kernel32.GlobalUnlock
memcpy = cdll.msvcrt.memcpy

def GetClipboardText():
   text = ""
   if OpenClipboard(c_int(0)):
       hClipMem = GetClipboardData(c_int(CF_TEXT))
       GlobalLock.restype = c_char_p
       text = GlobalLock(c_int(hClipMem))
       GlobalUnlock(c_int(hClipMem))
       CloseClipboard()
   return text

def SetClipboardText(text):
   buffer = c_buffer(text)
   bufferSize = sizeof(buffer)
   hGlobalMem = GlobalAlloc(c_int(GHND), c_int(bufferSize))
   GlobalLock.restype = c_void_p
   lpGlobalMem = GlobalLock(c_int(hGlobalMem))
   memcpy(lpGlobalMem, addressof(buffer), c_int(bufferSize))
   GlobalUnlock(c_int(hGlobalMem))
   if OpenClipboard(0):
       EmptyClipboard()
       SetClipboardData(c_int(CF_TEXT), c_int(hGlobalMem))
       CloseClipboard()

Here is a really nice piece of code which implements a TCP relay (tunnel) using Python's asyncore module. It's really interesting because the way I implemented it makes a lot of sense, in contrary to the same code written using select.

There's also something about using asyncore.dispatcher_with_send on Unix systems which might send an EWOULDBLOCK sometimes, but I didn't dig deep enough.

The 3 sockets playing a role here are:

* A Relay server socket - accepts connections from clients

* Relay clients, which trigger a new connection to the tunnel destination

* Relay connection for each relay client connected.

The cool thing about asyncore is that you can also decide if handle_read will be called or not, even if data is available, by overriding the "readable" function. In this implementation, a relay client does not start reading from a socket until the relay connection has been established successfully.

class RelayConnection(asyncore.dispatcher):
  def __init__(self, client, address):
      asyncore.dispatcher.__init__(self)
      self.client = client
      self.create_socket(socket.AF_INET, socket.SOCK_STREAM)
      print "connecting to %s..." % str(address)
      self.connect(address)

  def handle_connect(self):
      print "connected."
      # Allow reading once the connection
      # on the other side is open.
      self.client.is_readable = True

  def handle_read(self):
      self.client.send(self.recv(1024))

class RelayClient(asyncore.dispatcher):
  def __init__(self, server, client, address):
      asyncore.dispatcher.__init__(self, client)
      self.is_readable = False
      self.server = server
      self.relay = RelayConnection(self, address)

  def handle_read(self):
      self.relay.send(self.recv(1024))

  def handle_close(self):
      print "Closing relay..."
      # If the client disconnects, close the
      # relay connection as well.
      self.relay.close()
      self.close()

  def readable(self):
      return self.is_readable

class RelayServer(asyncore.dispatcher):
  def __init__(self, bind_address, dest_address):
      asyncore.dispatcher.__init__(self)
      self.create_socket(socket.AF_INET, socket.SOCK_STREAM)
      self.bind(bind_address)
      self.dest_address = dest_address
      self.listen(10)

  def handle_accept(self):
      conn, addr = self.accept()
      RelayClient(self, conn, self.dest_address)


RelayServer(("0.0.0.0", 8080), ("127.0.0.1", 1234))
asyncore.loop()

Iterating over a sequence of IPs in Python

I was bit bored, so I wrote a simple iterator that iterates over a sequence of IPs using a subnet bitmask.

import struct
import socket

class IPIterator:
def __init__(self, ip, bitmask):
 self.ip = ip
 self.bitmask = bitmask
def __iter__(self):
 ipnum = struct.unpack(">L", socket.inet_aton(self.ip))[0]
 mask = 2 ** self.bitmask - 1
 for x in xrange(ipnum & ~mask, ipnum | mask):
  yield socket.inet_ntoa(struct.pack(">L", x))

if __name__ == "__main__":
for x in IPIterator("1.2.3.4", 8):
 print x