Monday, June 17, 2013

AMS Android Library

The purpose of this post is to assist with the process of integrating AMS Android library and hopefully answer any possible questions you might have about it. It assumes that you have already gone through the setup instructions described in the README.MD file and added at least one application to your AMS Dashboard.

AMSLibrary.java is a Java class that allows your android application to communicate with AMS web service. Its purpose is to simplify the process of logging messages on a remote server for a developer by abstracting all required formatting and network communication, therefore, minimizing amount of code and error checking.

Step 1 is to add AMSLibrary.java to your project. There are two ways to do this. The first one is to simply add the .java file to your existing Android project. The second one is to create a JAR library and include it in your application. I will purposely not go into further details on how to accomplish this in my post because it is out of scope. However, if you do need further help with this step, feel free to reach out to us and we will gladly provide assistance.

Once the library is included in your project, you only need to piece of information to initialize it. First, you need to provide URL of the AMS web service. Assuming that you have gone through the initial setup, it should look something like this: http://your_domain/ams_location/AMS/webservice.
Secondly, you need to specify your application key. An AppKey is basically just a unique id that is generated when you create a new application in the AMS Dashboard. It enables the web service to correlate received messages with a particular application.

The next step is to create an activity that you want to log. Inside AMSLibrary there is AppActivity object which contains the following 4 properties: type ID, message, description and notes. Additionally, there are 4 types of messages that are currently supported: success, warning, error and info. Please note that the library doesn't enforce any rules on what kind of information you can send. Our goal is to enable developers to have as much flexibility as possible. However, for organizational purposes, we suggest that you use correct types for your messages. The rest of the properties are pretty self-explanatory and completely optional.

After you have created an activity object and populated it with information you want to send, the last thing you need to do is to call the logActivity function and pass your activity, and you are done! The AMSLibrary will send your data to AMS web service which will log it in your database. This makes your data instantly available via AMS Dashboard.

There are few important things that happen behind the scene. First of all, the communication between the library and the remote server is asynchronous which means that your application doesn't have to wait for the library to finish and can continue executing. This ensures that your application will never experience a performance hit even when a user is on a slow network connection or your remote server is unavailable for any reason. It is also important to mention that “out of a box” AMS setup doesn't support encryption. Which means that messages that are sent from your application to the server are transmitted in plain text. Our reasoning behind this decision is based on the fact that encryption adds overhead and is only needed when sending sensitive data. If, in fact, your application is logging sensitive information the amount of developing effort to switch to an encrypted protocol is minimal. Finally, the current version of AMSLibrary doesn't store any data locally. This has its advantages as well as drawbacks. The main benefit of not storing any data to a local hard drive is efficiency. However, if your user isn't on a network connection when the logActivity call is made, the data will be lost. Once again, we wanted to leave it up to developers how they choose to handle this situation.

Feel free to contact us if you have any questions about the AMS or its setup. As usual, we welcome any constructive feedback you might have.

Sunday, June 16, 2013

Arduino LED challenge

I met up with Brian and Dmitry for a few drinks the other day and they tell me that they completed a tutorial on how to turn on an LED by adding code to Arduino. Apparently it took them three hours. Now I've seen the tutorial and it looked incredibly simple. So, naturally, I scoffed in their faces and told them how bad they were at life. In turn, they decided to challenge me to do it too and  they even gave me a week. *Scoff again* "pffft, I'll do it in two days as long as you promise to give me all of the equipment I need". With mischievous smiles on their faces, they agree.

The next day comes around and I pick up the box with all of the wires, LEDs, Arduino, a multimeter, and some other miscellaneous items. I start early in the morning by first installing the Arduino IDE and pulling up the tutorial I need. Ok, not even 10 steps long. No big deal. 15 minutes go by and I've connected a 220ohm resistor to the D13 pin then the LED and then back into Arduino through the ground. Awesome, I have a complete circuit. Now to the code: simple copy & paste into the IDE, verify, and upload.

As expected by their smiles (and the fact that it took them a while to complete), it didn’t work. That’s fine; this isn’t my first time debugging something. Considering my main strength (programming), I figured I should look through the code first and make sure everything looks right. Yep, everything seems fine in the code. Not much that could go wrong in 20 lines.

A little bit out of my comfort zone already, I start looking through the hardware. I grab the multimeter and start checking voltages. Before the resistor, every second it alternates the output from 0V to 5V. After the resistor, it goes down a little bit which is also to be expected. Then after the LED it goes down to 1.5V and 0V.

The fact that Arduino is alternating between 5V and 0V shows that the code is working. And there is current all the way from D13 to ground so all of the connections are touching. Maybe a broken LED? Can they even break and still keep the connection intact? Doesn’t matter, I replace the LED with a new one. Still not working.

After an hour and a half of building, rebuilding, and questioning any assumptions I’ve made I decide to look around online and do some more research. I start with Arduino: look up D13, maybe it has some special property that doesn’t work? That wasn’t it. Read some more about the actual board, maybe I need some enable pin or something. No. Two hours in and I’m starting to panic because my goal of finishing before they both completed is coming up (yes, I have to one-up them).

Then I look up the resistor, maybe it’s on the wrong way? Apparently that’s not possible. Although, I would be lying to say that I didn’t try it out anyway. How about the LED? I look up the part number on Adafruit . Then I notice the title is “Super-bright 5mm IR LED (25 pack)”. IR = Infra-Red. It doesn’t matter how bright these “Super-bright” LEDs are: I CANNOT SEE INFRA-RED. I rush to grab my phone camera (because it can see that section of the spectrum) and low and behold, there it is lighting up every second.

Victory. 2.5 hours later. Ugh the frustrations: who the hell gets IR LEDS anyway?

Friday, June 14, 2013

Current Project: Application Monitoring Service (AMS)

Zetta7's current project is a way to bring logging information for mobile applications to a central location. It runs on PHP/MariaDB (or MySQL) with a small library file to be included with the mobile application. Right now we're working with Android but will be expanding to Windows Phone and iOS in the future. 

The goal is to be very versatile and allow the developer to collect information which they deem necessary. All that is required is to give the entry a type which can be Warning, Error, Information, Success. Add a message to the entry and you're under way. The AMS webservice will accept these calls in the background which is transparent process and will not bother your users. 

Once the AMS web service stores the entry then its time for the dashboard to present that information to you in graph form. The graphs can help discover trends, issues or just general knowledge of what are the hot area's of your application. If you prefer, you can dump the data into a csv to easily be worked into a presentation or just further, more detailed research.

You can check the project out on git-hub at https://github.com/Zetta7LLC/AMS.

For more information on our projects check out our projects page at http://zetta7.com/projects.php.

Z is for Zetta!

Zetta7 is a company started in Bellevue, WA between a few friends with a common interest in producing tech. We started with the idea of creating Android applications but have quickly adapted our vision to much more than that. We spend a lot of our time researching and learning about new things that spark our interest.

Our current goal is to learn new things and solve problems which may help us do that. Along with that goal, we hope to someday create something that you may find useful. 

This blog is a place for us to direct our focus and put things into words and maybe reference at a later date. Its really easy to spend a ton of time on a project and never flush the knowledge out anywhere. We're hoping to solve that by simply blogging about it. Some things may be pretty mundane, spending a few hours on a simple circuit (You'll quickly learn we are NOT Electrical Engineers). If this information helps you at all, thats great! If we talk about something which you're interested in getting a little more detail about, reach out to us. We're mostly friendly. Mostly.

Check out our website http://www.zetta7.com/ it has a little more detail on past projects and a little more information about us individually.