Iconeme Launches Bluetooth Beacon Solution for Mannequins - See more at: http://www.rfidjournal.com/articles/view?11637#sthash.O7cx1eLD.dpuf
A link to a video describing their VMBeacon
These are nothing compared to what is coming. Already I have the capability to do what these mannequins do with a simple computer like the Arduino series. By adding a servo and an ultrasonic sensor I will be able to detect and count customers and even give them "eye contact" maybe even a wink. I am researching using Synthetic Aperture Sonar techniques in order to apply their benefits to short range ultrasonic arrays. My "Ultrasonic Flashlight for the Blind" will be an interesting test bed for some techniques that can lead to great applications. I can't wait for a mannequin to tell me where the "big and tall" department is!
#arduino #bluetooth
Tuesday, April 22, 2014
Sunday, April 20, 2014
Ultrasonic Flashlight for the Blind
I finished the preliminary design and I have begun the prototyping phase for my "Ultrasonic Flashlight for the Blind". I will be using an ultrasonic generator/receiver attached to an Arduino Nano together with a three axis accelerometer and a four output motor controller to four motor vibrators in the flashlight handle. The goal is to provide ultrasonic ranging feedback based on X Y Z orientation. The design is inspired by the Amazon River Dolphin which is a dolphin with a the ability to scan its head back and forth in order to navigate and hunt in murky flood waters in the Amazon Forest. Stay tuned for progress.
Tuesday, March 25, 2014
Hangout for World Arduino Day March 29,2014
I will be hosting a hangout for Arduino Day on March 29, 2014. Arduino Day Hangout from Kenosha Wisconsin I have been doing a lot of work on using Bluetooth to communicate between many things and Android. One of the devices was the RFduino that I had ordered earlier. Unfortunately the RFDuino people hit a big snag and they received a black eye fro the open source community regarding their handling of an open source software license. It was a major problem for me because without the open source software to download code to the computer chip it was useless. Fortunately, a fellow blogger devised a way around the problem of programming them so I did get them to work.
The problem with being unable to even send a program to the chip was only the start of my problems. One little understood problem with Bluetooth is the proprietary nature of what is called the "Bluetooth Stack". The Bluetooth Stack is based on specifications from the Bluetooth SIG and it is a framework of different data structures and functions that are normally associated with different hardware such as keyboards, mice, audio players and an extensive list of other types of devices. Needless to say, the data and functions exchanged or required would be differ from a Bluetooth keyboard to those required by a Bluetooth bicycle computer. And on top of all those differences their are different versions of Bluetooth to contend with. As if I didn't have enough ambiguity then there is the problem of different versions of operating systems, each of which has their own Bluetooth stack. Not only do they have their own stack they are also in the process of rewriting it for various reasons.
The reason that I finally swore off working on a Microsoft based computer and switched to Linux (I use Ubuntu) was an incident where I was installing a Bluetooth based set of headphones. I would go through the install and they would work flawlessly until I rebooted the computer. When I rebooted they were nowhere to be seen or heard from. After doing it a few times thinking that I must not have done something right I decided to watch the reboot closely and I discovered that Windows discovered that a new Bluetooth stack had been installed and it uninstalled it and installed it's own version which didn't support the headphones. The lesson that I learned is that if both the manufacturer and the operating system are not on the same page Bluetooth won't work properly. Even worse, it might work until one of them decides to change their software.
For whatever reason they give, neither the manufacturer of the chip nor the the operating system (other than Linux) will show you the source code for their Bluetooth stacks. An analogy that comes to mind is that it is like two black boxes communicating via smoke signals. You may be able to see he smoke but you are left to guess as to what was meant by one black box and what is inferred by the other. Added to that is the fact that Bluetooth communicates using what is called Adaptive Frequency Hopping where each smoke signal appears (maybe, but not always) on different frequency. So now it becomes like reading smoke signals on a windy day. And now the problem of security comes up and they want to encrypt the packets too!
Please keep in mind that my projects were to investigate two things, an indoor guidance system for the visually impaired and ans an unobtrusive product information beacon. I want to design a cheap hardware system to send minimal information like a geographic location and or navigation hazards. All of this was desire was based on the lure of Bluetooth Low energy devices. Despite all of the hype you might hear I can tell you that there are significant barriers to designing such a system.
So what's a guy like me supposed to do?
I am working on what I call Anonymous Bluetooth. By understanding the communications between the host and the client I am trying to design a system to craft packets that will bypass the security and complexities of the Bluetooth stacks.
The way I plan to get it to work is by using a robust protocol (the original) called SPP Serial Port Protocol. It is universally supported by every Bluetooth stack that I have ever seen. What I intend to do is to craft packets using a cheap Arduino computer and transmit them to channels that I know will be received by the client.
By properly choreographing the packets the client's implementation of Bluetooth will be happy. The way it will work in practice is the client will pair once with one of my computers and it will appear to be a SPP device with a known UUID or MAC address. All of the relevant pairing data is passed to the neighboring beacons. The neighboring beacons monitor the RSSI (signal strength) and packets being passed. If the client device is in another beacon's reach the tow beacons communicate on another channel (not necessarily using Bluetooth protocols) and they mutually decide to hand off the client to the new beacon. Any pending communications are exchanged between the beacons and the client has no idea that it is not still communicating with the new beacon.
Basically what I intend to do is bypass the Bluetooth stack on the beacon side and spoof packets to the client side while keeping track of where the client is.
In practice this is how it will work for the visually impaired. The visually impaired person is informed of the system and helped to initiate a pairing with a beacon. They now want to go from eye department to the x;ray department. Since the Arduino that I am testing has been outfitted wit SD Card reader (currently 4 G byte) it will have an extensive list of destinations and hazards to watch out for during the journey. Hopefully their device will have a magnetometer to tell them the direction of their next way point. The Arduino based beacons can send both audio and visual cues to the client on demand. The client's current location is passed token ring style to a master server so that the client's progress can be followed. The client's destination beacon is informed that it has a client coming. A missing client search can be conducted by passing a token around to which with a location and time stamp information is added.
The way it will work for commercial applications is very similar. A client pairs with the 'real' device at the door of the business. The client is once again passed from beacon to beacon only this time the beacons have a list of products and or specials in it's domain along with the shortest route from one beacon to another.
The problem with being unable to even send a program to the chip was only the start of my problems. One little understood problem with Bluetooth is the proprietary nature of what is called the "Bluetooth Stack". The Bluetooth Stack is based on specifications from the Bluetooth SIG and it is a framework of different data structures and functions that are normally associated with different hardware such as keyboards, mice, audio players and an extensive list of other types of devices. Needless to say, the data and functions exchanged or required would be differ from a Bluetooth keyboard to those required by a Bluetooth bicycle computer. And on top of all those differences their are different versions of Bluetooth to contend with. As if I didn't have enough ambiguity then there is the problem of different versions of operating systems, each of which has their own Bluetooth stack. Not only do they have their own stack they are also in the process of rewriting it for various reasons.
The reason that I finally swore off working on a Microsoft based computer and switched to Linux (I use Ubuntu) was an incident where I was installing a Bluetooth based set of headphones. I would go through the install and they would work flawlessly until I rebooted the computer. When I rebooted they were nowhere to be seen or heard from. After doing it a few times thinking that I must not have done something right I decided to watch the reboot closely and I discovered that Windows discovered that a new Bluetooth stack had been installed and it uninstalled it and installed it's own version which didn't support the headphones. The lesson that I learned is that if both the manufacturer and the operating system are not on the same page Bluetooth won't work properly. Even worse, it might work until one of them decides to change their software.
For whatever reason they give, neither the manufacturer of the chip nor the the operating system (other than Linux) will show you the source code for their Bluetooth stacks. An analogy that comes to mind is that it is like two black boxes communicating via smoke signals. You may be able to see he smoke but you are left to guess as to what was meant by one black box and what is inferred by the other. Added to that is the fact that Bluetooth communicates using what is called Adaptive Frequency Hopping where each smoke signal appears (maybe, but not always) on different frequency. So now it becomes like reading smoke signals on a windy day. And now the problem of security comes up and they want to encrypt the packets too!
Please keep in mind that my projects were to investigate two things, an indoor guidance system for the visually impaired and ans an unobtrusive product information beacon. I want to design a cheap hardware system to send minimal information like a geographic location and or navigation hazards. All of this was desire was based on the lure of Bluetooth Low energy devices. Despite all of the hype you might hear I can tell you that there are significant barriers to designing such a system.
So what's a guy like me supposed to do?
I am working on what I call Anonymous Bluetooth. By understanding the communications between the host and the client I am trying to design a system to craft packets that will bypass the security and complexities of the Bluetooth stacks.
The way I plan to get it to work is by using a robust protocol (the original) called SPP Serial Port Protocol. It is universally supported by every Bluetooth stack that I have ever seen. What I intend to do is to craft packets using a cheap Arduino computer and transmit them to channels that I know will be received by the client.
By properly choreographing the packets the client's implementation of Bluetooth will be happy. The way it will work in practice is the client will pair once with one of my computers and it will appear to be a SPP device with a known UUID or MAC address. All of the relevant pairing data is passed to the neighboring beacons. The neighboring beacons monitor the RSSI (signal strength) and packets being passed. If the client device is in another beacon's reach the tow beacons communicate on another channel (not necessarily using Bluetooth protocols) and they mutually decide to hand off the client to the new beacon. Any pending communications are exchanged between the beacons and the client has no idea that it is not still communicating with the new beacon.
Basically what I intend to do is bypass the Bluetooth stack on the beacon side and spoof packets to the client side while keeping track of where the client is.
In practice this is how it will work for the visually impaired. The visually impaired person is informed of the system and helped to initiate a pairing with a beacon. They now want to go from eye department to the x;ray department. Since the Arduino that I am testing has been outfitted wit SD Card reader (currently 4 G byte) it will have an extensive list of destinations and hazards to watch out for during the journey. Hopefully their device will have a magnetometer to tell them the direction of their next way point. The Arduino based beacons can send both audio and visual cues to the client on demand. The client's current location is passed token ring style to a master server so that the client's progress can be followed. The client's destination beacon is informed that it has a client coming. A missing client search can be conducted by passing a token around to which with a location and time stamp information is added.
The way it will work for commercial applications is very similar. A client pairs with the 'real' device at the door of the business. The client is once again passed from beacon to beacon only this time the beacons have a list of products and or specials in it's domain along with the shortest route from one beacon to another.
Friday, January 24, 2014
Android Application Signing For Fun and Profit
I am currently enrolled in a awesome series of classes involving developing Android applications for mobile in which over 140,000 students are enrolled in the first class. The whole series is a groundbreaking example of Massive Open Online Courses (MOOC). I predict that this series will really turn out to be historical in the fact with so many students interacting the course is going to go from 'Semi-Contolled Chaos" to 'Nuclear Ignition'. For example, one student tried to run and an example and received a weird application signing error. He then posts the error where everyone (in Google+ group for the course) including the instructor can share his 'pain'. So I decided to investigate the error and it lead me to the application signing process. Most people (including me) might think that the signing process will be bridge that cross when your application is done. As it turned out what I discovered is that the process is one that really needs to covered 'early and often' especially in a day in a day where some people worry about their credit cards going through a metal detector. Google has excellent page discussing the subject of application signing.
This post is about what I feel I need to know and should not be viewed as complete discussion of the issue. I literally am switching back and forth from multiple documents on the subject and I am going to paste entries from them that I feel are germane to my situation. My goal is to present a 'readers' digest' version so fellow students can quickly understand what they need to know about application signing.
First up "Why do applications need to be signed?" It might seem to be an obvious question with an obvious answer but I will posit that it is little more complex than one might sense at first glance.
According to Google:
I been have told that I can supersede Google applications that are included in the top layer of the Android stack but I wonder about the mechanism of doing so it avoids the signature process. I think that Google might take offense if I go around signing my apps as "Sincerely yours, Google".
So what's an honest programmer to do? No problem, Google has a few tricks up it sleeves for the artist in training.
There is a lot of valuable information about the whole process that falls outside the scope of this article. Google is the replacement for the looking glass from Alice in Wonderland. Start with the page that I listed at the top of this article and follow the links contained therein down the rabbit hole of application signing in android. If you see the Cat in the Hat ask him if he got his hat from the Mad Hatter?
One last important thing from Der Google:
(make note of the 'skip to' sorta reminds me of the GOTO command)
This post is about what I feel I need to know and should not be viewed as complete discussion of the issue. I literally am switching back and forth from multiple documents on the subject and I am going to paste entries from them that I feel are germane to my situation. My goal is to present a 'readers' digest' version so fellow students can quickly understand what they need to know about application signing.
According to Google:
The Android system requires that all installed applications be digitally signed with a certificate whose private key is held by the application's developer. The Android system uses the certificate as a means of identifying the author of an application and establishing trust relationships between applications. The certificate is not used to control which applications the user can install. The certificate does not need to be signed by a certificate authority: it is perfectly allowable, and typical, for Android applications to use self-signed certificates.So I have to sign all applications but I could sign them as "Elvis Presley"? What I infer from their statement is that all applications have some manner of tracking software with a unique identifier that will ultimately be able to differentiate varying applications and varying authors. What happens if 'Elvis' tries to write an application named the same as one written by 'Sigmund'? The answer is a big fat peanut butter and banana error! Android will tell you it can't install the 'Elvis' authored app without first uninstalling the 'Sigmund' authored app.
I been have told that I can supersede Google applications that are included in the top layer of the Android stack but I wonder about the mechanism of doing so it avoids the signature process. I think that Google might take offense if I go around signing my apps as "Sincerely yours, Google".
So what's an honest programmer to do? No problem, Google has a few tricks up it sleeves for the artist in training.
To test and debug your application, the build tools sign your application with a special debug key that is created by the Android SDK build tools"Honey, Have you seen my keys, I can't find my special debug key?" It turns out that there are different signatures which allow a programmer to write code and have them automatically signed in a debug mode. When you are ready to cash in on your application you will have to rebuild it with a suitable private key. So for the beginning programmer all you need to know is that there is a process involved in tracking application authorship and that there is a thing called a 'debug certificate' that should automatically be generated for you when are developing an application. Down the road you will have to replace the debug certificate with a private certificate before deploying your application. If you start getting certificate errors it is because something has gone wrong with the automatic creation of the debug certificate or some reasonably expected error such as you were trying to install the same application name on a device that you previously used a different development system so the same application has a different 'debug certificate'. Fix it: Read the error and follow the instructions... yeah!
There is a lot of valuable information about the whole process that falls outside the scope of this article. Google is the replacement for the looking glass from Alice in Wonderland. Start with the page that I listed at the top of this article and follow the links contained therein down the rabbit hole of application signing in android. If you see the Cat in the Hat ask him if he got his hat from the Mad Hatter?
One last important thing from Der Google:
(make note of the 'skip to' sorta reminds me of the GOTO command)
Signing in Release Mode
When your application is ready for release to other users, you must:
- Obtain a suitable private key
- Compile the application in release mode
- Sign your application with your private key
- Align the final APK package
If you are developing in Eclipse with the ADT plugin, you can use the Export Wizard to perform the compile, sign, and align procedures. The Export Wizard even allows you to generate a new keystore and private key in the process. So if you use Eclipse, you can skip to Compile and sign with Eclipse ADT.
Thursday, January 23, 2014
Issues concerning Computer Systems for Android Development
There are many choices to be made when you decide that you want to start developing programs for Android devices. Perhaps the first choice that you probably have made already is what operating system you will be using to develop on. It seems a bit ironic, but to my knowledge there are no Android based systems (other than web browser based systems) that are currently capable of developing software to run on Android itself. After you gain an understanding how Android works under the hood you will understand that it is unlikely that any development system will ever be viable running on Android. Most likely the next generation will involve something like a Chrome operating system linked to a cloud based development system and I wouldn't be surprised if that happens soon due to the explosive growth in cloud computing. So here are your choices: Windows, Mac or Linux. I have done development on Windows and on Linux but not on a Mac system. if you are looking for advice on a Mac system you are in the wrong place. When it comes to Windows, I used to develop in Windows a few years ago and it worked OK but I became frustrated with the way Microsoft was dealing with the Bluetooth stack which is a pretty obscure issue for most but for me it was a 'deal breaker'. I now proudly tell head hunters "I don't do Windows".
The only caveat I have is that when upgrading to a whole new version I have run into some compatibility issues and I have in the past had to downgrade to an earlier version in order to get everything working again. Be very wary of getting the latest version of anything without knowing whether it is fully working. Case in point there is JDK 7 out but you may have problems with compatibility with some areas. If you are just starting out go with what the masses are using.
If you are reading this chances are you already have a computer and you are considering setting up a development system. I recommend that you assess your computer by examining it in detail. How much memory do I have? How many slots for memory does the motherboard have? What microprocessor does it have? Is the microprocessor Intel or AMD? Is the microprocessor 32bit or 64bit? How many cores does it have? How many threads can it run? What kind of hard drive do I have? How fast is the hard drive? For the uninitiated, these questions might seem quite difficult. Do not fear because the answers to all of those questions are easily answered by searching the internet.
The issues that I am going to discuss will apply equally to both Windows and Linux based systems. A frequent question that I get is "which distro do I use"? I have had experience on multiple distributions of Linux and I have seen them rise to prominence and fall from prominence based more on their business model than their features. The truth be known is they all run on a 'kernal" which is the actual operating system under the hood. Think of it as they all have the same horse and they each have their own buggy hooked to it. So they each will work as development platform the only things that will change will be software package mangers and the like. And just like every other operating systems updates occur at a regular basis and as matter of convenience you want a distribution that is easy to update without disturbing your development system. I currently use Ubuntu 12.04 LTS and the LTS stands for long term support. Their business model as far as I know is based on selling support to companies that use their distribution and they seem to be quite stable. Software updates are almost automatic in that they will show up as being available and you have to allow them to happen. Ubuntu uses a user interface called Unity and it takes a little getting used to but I have grown accustomed to it.
The only caveat I have is that when upgrading to a whole new version I have run into some compatibility issues and I have in the past had to downgrade to an earlier version in order to get everything working again. Be very wary of getting the latest version of anything without knowing whether it is fully working. Case in point there is JDK 7 out but you may have problems with compatibility with some areas. If you are just starting out go with what the masses are using.
There are a few choices for a Integrated Development Environment out there but the standard is currently based on Eclipse. Eclipse is a wonderful and powerful IDE but the problem is it takes a lot of "horse power" (remember my horse and buggy analogy) The other problem is it is downright intimidating when you first see it. There are so many features and settings that by the time you learn them all you will have at least forgotten a few. Don't be fearful because for every feature that Eclipse has there are probably three tutorials on the internet showing their use. When you realize that you can't remember everything you will discover it is more important where to look when you want to do something. One nice feature of the Unity interface on Ubuntu is the ability to have four desktop workplaces to switch to and from at the click of a mouse. It is very handy to a browser open to a tutorial and then the Android SDK in another.
So here is the problem: You want get into developing Android but you don't want spend the five to six hundred bucks for a new computer that will have enough "horse power" to make your ride enjoyable. I use a "beater" laptop that I bought used more than two years ago and it was year old at that time. Somewhere there is a derivative to Moore's Law that states as computers become more advanced they will consume more resources. I am cheap because I am poor. I don't spend anything unless I have to. Yes, I would like to be able to fork out $1000 on a new computer that would make my life a little easier but I can't afford to. I know that there are a lot of people that are looking to learn Android in order to improve their lives and so I am writing this in order help you make the most of you what you have.
If you are reading this chances are you already have a computer and you are considering setting up a development system. I recommend that you assess your computer by examining it in detail. How much memory do I have? How many slots for memory does the motherboard have? What microprocessor does it have? Is the microprocessor Intel or AMD? Is the microprocessor 32bit or 64bit? How many cores does it have? How many threads can it run? What kind of hard drive do I have? How fast is the hard drive? For the uninitiated, these questions might seem quite difficult. Do not fear because the answers to all of those questions are easily answered by searching the internet.
First lets talk about your microprocessor. Go to your system settings and look for the processor and memory installed. Next open a browser and Google the exact description for the microprocessor as it appears on your system settings. Scroll through the results until you see a spec sheet from the manufacturer. Take note of how many cores (more is better), how many threads (more is better) and whether it is 32bit or 64bit. Surprisingly, the clock speed is one of the least important specs since most processors run in the GHz range. A single core processor running at 1.5 GHz is not as good as a dual core multi-threaded processor running at 1.2 GHz.
Now lets talk about your motherboard. Look for the name and model number of your computer and type them into the Google machine with word 'specifications' or 'manual' after it. Scroll through the results and find a manual and look for the maximum supported memory and how many memory slots it has. What you want to answer is can I expand the memory and how cheap can I get by? On my computer 1GB was OK until I upgraded the operating system. I went ot 2GB and it helped a lot. My system is limited to 2GB without flying outside the box. When it comes to developing Android you can't have too much memory. So in my case the computer had two slots and 1GB of memory installed so I ordered two 1GB sticks to upgrade to 2GB. How did know that both slots were in use? Manufacturers are cheap, they would rather put two smaller sticks instead of one larger stick because they could save a buck or two. Beside that you should always match the memory when you are upgrading. If one is rated at 300Mhz and another at 600 Mhz and your system is compatible with the 600 MHz stick it will run at the 300 Mhz speed in order to accommodate the slower memory. Memory will be your cheapest upgrade so splurge.
Next lets talk about 32bit versus 64bit microprocessors. Both will work but they will use different versions of the operating system in order to take advantage of the more modern 64bit processors. The bottom line is that you get what you have in the computer. It is rarely, if ever feasible to upgrade to a 64 bit processor on a motherboard that has a 32bit processor. The only advantage that I see with Intel versus AMD when it comes to Android is that Intel has the HAXM virtualization stuff going on that is supposed to significantly speed up the emulator in the Android SDK. I haven't seen the equivalent for AMD. (even though it may exist) The bottom line is I have to do without since my system is 32bit. My next system will be 64bit Intel unless things change by the time I upgrade.
Another bottleneck you system will encounter is the hard drive. It turns out that the size of the hard drive has become a great selling point but is not really that important. Yes, you need some room but the amount of storage you have isn't as important as to how fast you can retrieve it or store it. In Ubuntu you can use the disk utility to see what kind of hard drive you have along with everything else you might be interested in. It includes a self test routine and a speed test (read only if the drive is mounted).
My hard drive was acting suspiciously so I opted to replace it with a Solid State Drive. Without going into too much detail the old hard drive relied on spinning discs of magnetic memory and the new hard drive is really just static memory chips arranged to look like a hard drive to my system. I bought a 64Gb replacement and swapped it out and re-installed everything. The old hard drive averaged 23 MBsec and the new one about 65 MBsec. The difference was very significant in everything I do on the computer and it was well worth the $75 bucks I spent. Be forewarned that Solid State Drives are a work in progress and mine has already crashed twice and the manufacturer is not exactly easy to work with. I ordered a 64Gb thumb drive and I plan to clone the hard drive automatically every night. Yes, I would like to have one that was more reliable but my system won't support the more modern drives from reputable manufacturers.
Unfortunately the standard backup routines don't really back up your entire system. I have used the program 'dd' before in order to clone drives automatically so I am hoping that the problem goes away as the hard drive maps away its bad sectors. In the mean time I will have a fresh clone to restore everything to its last running state. Annoying yes, but it is a lot easier to reclone it than it is to re-install the operating system. One job takes minutes and the other involves hours. Besides that you can always boot to the clone in a pinch.
In conclusion, upgrade your memory and consider switching to a solid state drive.
Update: I tried reformatting my rescue USB stick with an updated version of 12.04 (so I wouldn't have 512 updates) and it wouldn't boot. I switched to 13.10 and had success so I installed it to my SSD. I had to re-install Chrome and had to use the version from Ubuntu. I also had to re-install the OpenJDK6-jre. The android SDK them worked so far. You have to enable workspace switching in appearances in 13.10.
Found a problem after upgrading to Ubuntu 13.10
There is a work around in the article that works but not exactly as expressed (for me). I have the menus working and it is too much work to go back. Found the problem only after building an 8Gb usb 2.0 drive that has an entire development system on the 8Gb stick. It works but there was very little space left. I recommend at least 16Gb and I don't recommend it as your main system. I built it as an emergency boot to copy (using dd) a 64 Gb image over to my SSD in case it fails again. Just for entertainment I wanted to see if I could fit the entire development system on the 8 Gb stick. Answer Yes but only about 250 Mb to spare. By the way you have to install Chrome by downloading it manually and installing via apt (search web for instructions)and definitely not by the Ubuntu Software manager.
The bottom line is the new release comes with free bugs.
Update: I tried reformatting my rescue USB stick with an updated version of 12.04 (so I wouldn't have 512 updates) and it wouldn't boot. I switched to 13.10 and had success so I installed it to my SSD. I had to re-install Chrome and had to use the version from Ubuntu. I also had to re-install the OpenJDK6-jre. The android SDK them worked so far. You have to enable workspace switching in appearances in 13.10.
Found a problem after upgrading to Ubuntu 13.10
There is a work around in the article that works but not exactly as expressed (for me). I have the menus working and it is too much work to go back. Found the problem only after building an 8Gb usb 2.0 drive that has an entire development system on the 8Gb stick. It works but there was very little space left. I recommend at least 16Gb and I don't recommend it as your main system. I built it as an emergency boot to copy (using dd) a 64 Gb image over to my SSD in case it fails again. Just for entertainment I wanted to see if I could fit the entire development system on the 8 Gb stick. Answer Yes but only about 250 Mb to spare. By the way you have to install Chrome by downloading it manually and installing via apt (search web for instructions)and definitely not by the Ubuntu Software manager.
The bottom line is the new release comes with free bugs.
Monday, January 20, 2014
Android Programming... All aboard! Last Call!
Programming Mobile Applications for Android Handheld Systems is starting tomorrow so anyone interested in learning should jump on board. The course has the first three lectures available already at this link. The first lecture is a very well done overview of the Android system. The next two lectures are about the Android Development Kit. Even if you are a 'seasoned developer' I recommend viewing the lectures multiple times because each time you view them the context in your brain will find something new to think about and subsequently you will learn something new each time. In addition the presenter quotes some links for additional information that should be followed.
The second and third lectures are about the Integrated Development Environment. As of today the first assignments are not available but all of the examples are up on Github. What is Github? Github is a Concurrent Version System that allows a user to post files that can be used by others without interfering with changes made by other users. It might seem confusing as to why you want to have such a system but it will become clear when you want to have multiple people working on multiple files regarding a project. For example, you could have a graphic designer working on pictures for icons, a lawyer working on an End Use Agreement, one programmer working on animations, one graphic designer doing drawings and so on. With a Concurrent Version System they all work separately and then when they are happy with their updates they post their changes where everybody else gets them. Get it? Git Hub! Here is a tutorial on using it. Don't let it scare you because it is a lot easier than it looks. All you need to know at first is how to create an account, find the repository you are interested in and download the files you are interested in. Easy Peasy!
The next issue are the links that the presenter flashes on the screen. These links are very important and you should stop the video and open the link to Getting Started and bookmark it because it is the first door to a huge area of help and understanding about programming in Android. The next link of importance is the link to a YouTube video about the Dalvik system as used by the Android Operating system. For the uninitiated it will be 'Gobbly Geek Gook' but it is a very good video to sit back and count how many sentences are in English and how many you think are in Icelandic. They are all in English but not many people know what a 'nop' is. The Dalvik Virtual Machine is slated to be replaced with the Android Run Time in the near future but you can rest assured that it will operate based on the same basic constraints that drove the development of the Dalvik system. In short when the a new YouTube video comes out explaining the Android Run Time you will still swear that the presenter has switched to speaking in Icelandic! 'Nop' á íslensku er það sama og á ensku. ('Nop' in Icelandic is the same as it is in English. NOP is a programming acronym for No Operation.
Here is a link to the Video on the Dalvik Virtual Machine Internals.
The second and third lectures are about the Integrated Development Environment. As of today the first assignments are not available but all of the examples are up on Github. What is Github? Github is a Concurrent Version System that allows a user to post files that can be used by others without interfering with changes made by other users. It might seem confusing as to why you want to have such a system but it will become clear when you want to have multiple people working on multiple files regarding a project. For example, you could have a graphic designer working on pictures for icons, a lawyer working on an End Use Agreement, one programmer working on animations, one graphic designer doing drawings and so on. With a Concurrent Version System they all work separately and then when they are happy with their updates they post their changes where everybody else gets them. Get it? Git Hub! Here is a tutorial on using it. Don't let it scare you because it is a lot easier than it looks. All you need to know at first is how to create an account, find the repository you are interested in and download the files you are interested in. Easy Peasy!
The next issue are the links that the presenter flashes on the screen. These links are very important and you should stop the video and open the link to Getting Started and bookmark it because it is the first door to a huge area of help and understanding about programming in Android. The next link of importance is the link to a YouTube video about the Dalvik system as used by the Android Operating system. For the uninitiated it will be 'Gobbly Geek Gook' but it is a very good video to sit back and count how many sentences are in English and how many you think are in Icelandic. They are all in English but not many people know what a 'nop' is. The Dalvik Virtual Machine is slated to be replaced with the Android Run Time in the near future but you can rest assured that it will operate based on the same basic constraints that drove the development of the Dalvik system. In short when the a new YouTube video comes out explaining the Android Run Time you will still swear that the presenter has switched to speaking in Icelandic! 'Nop' á íslensku er það sama og á ensku. ('Nop' in Icelandic is the same as it is in English. NOP is a programming acronym for No Operation.
Here is a link to the Video on the Dalvik Virtual Machine Internals.
Friday, January 17, 2014
Subscribe to:
Posts (Atom)