Version Control System with Git

Version Control System

Most Version Control Systems (VCS) around, such as CVS and SVN depend on a centralized server where all the code is maintained and everyone go to share the code. One problem with that is that you need to be connected to the server to do any repository action, such as to see what has changed in a specific class since last update. This is no problem if you are connected to the network with a cable, but it is certainly a problem when you are out of WiFi range.

Git is different because everyone maintain the entire repository. so every repository operation can be performed off-line. There are other advantages in using git, but this one item is good enough for me.

There are Git command line installations for Windows, and Mac, and it is part of many Linux installations. In addition there is a plugin for Eclipse called EGit that makes it very simple to use.

Pages: 1 2 3

Android Software Architecture Conclusion

Android Software Architecture

This is the fourth installment of the Android Software Architecture Series. Please see prior posts:

• Part 1 – Android Software Architecture – Introduction
• Part 2 – Android Software Architecture – Background
• Part 3 – Android Software Architecture – Results

Validation

The most effective validation that we can achieve is by the implementation of JUnit tests on our new architecture. These tests were accomplished by following the Advanced Android Development by Mark Murphy starting on chapter 41.

There is no doubt that tests are much more effective and simple after we are able to streamline our views and our activities. Below is a simple JUnit test that checks the creation of the Activity, View and the browser component. Much more extensive tests are possible.

Android Software Architecture – Results

Android Software Architecture

This is the third installment of the Android Software Architecture Series. Please see prior posts:

• Part 1 – Android Software Architecture – Introduction
• Part 2 – Android Software Architecture – Background

Results

A simple WebView application will serve as a sample for the demonstration. The sample application has its origin on the excellent book by Mark L. Murphy. The WebView, and ListMenu demo projects were combined for the framework of this report. The application is basically a custom browser with a set number of URL addresses. It is useful if you access a single or a few web pages regularly. In this case, as you start the application, the designated page is immediately displayed.

Android Software Architecture – Background

Android Software Architecture

This is the second installment of the Android Software Architecture Series. Please see prior post:

• Part 1 – Android Software Architecture – Introduction

Background

Here are some basic guidelines of good design to assure that our new pattern has a sound architecture. We will be following, as close as possible, the SOLID Design principles introduced by Robert Martin on his 2002 book Agile Software Development: Principles, Patterns, and Practices, available short discussion on-line here. The first two rules directly motivate the MVC pattern, and the last three actually enable the process of applying MVC to the Android platform through careful design and implementation of abstractions and interfaces.

Android Software Architecture Project

Android Software Architecture

Introduction

Every software application has a structure; this structure can result from the efforts of a software architect or default chance. The default structure emerging from most Android applications is an object-centric architecture generally following the constraints of the basic Android Activity, Views, Categories and Intent classes with code concentrated on the Activity classes, controlling workflow and parsing views. This resulting structure may be acceptable for simple applications. But if the intention is to build a large, complex application, then a careful designed architecture will result in a good return on the investment, allowing manageable scalability, maintainability, robustness, reliability, reusability and superior performance on the limited resources of a portable device.

Conclusion of the Android Components Class

The Android Components Class is now over, so this series on Android Requirements is complete.

The purpose of the posts was to explore software modeling thought the Eclipse Modeling Framework (EMF). That was achieved.

I’m happy to report that I did get a very good grade. However there are more to do. Eventually I do intent to return to this project and complete the OCR component.

Building the Tesseract NDK library for Android

My project for my Android Components graduate class at FAU (COT6930) was a component to allow programmers better access to the Optical Character Recognition (OCR) package Tesseract maintained by Google.

The issue with this library, is that it is written in C and C++. It contains not only the OCR library, but also the Leptonica Image Processing Library.

Available Resources

We have the Android Native Development Kit (NDK) that offers the means of utilizing code written in C and or C++ in our Android programming. However the process of compiling and preparing those libraries is very complex, lengthy and error prone. Below I describe the process; however after my component will allow users to have a more direct access to the OCR libraries on  their own Android development.

We have available the excellent work of Robert Theis with his tess-two project. Tess-two uses the Tesseract project and adds the Android Java Native Interface (JNI) to allow compilation for the Android platform, complete in an Eclipse project.

Application Engineering – Requirements Gathering Part 5

Model Implementation and Testing

This post is in reference to Project Assignment 4 for my graduate course COT6930; Android Components.

As the previous three parts on this series, this post is also based on the book “EMF Eclipse Modeling Framework”.

Links for the other parts are: Part one, Part two, Part three and Part four.

On Part four of this series, we had our model ready to produce java code with the EMF generator model (see Part 4). Now we will produce the java classes described in our System Class Diagram.  This process will also follows the excellent EMF tutorial by Vogella.com.

Application Engineering – Requirements Gathering Part 4

System Analysis – Class Diagram

This is Part four of the  Android Components Class project, but corresponds to Project Assignment 3 of my Android Components Class.

Links for the other parts are: Part one, Part two and Part three.

This post will present the result of the System Analysis as a class diagram and an Eclipse Modeling Framework (EMF) model, ready to produce an Eclipse plug-in Framework code.

Javadoc Notes

Javadoc allows not only to comment the code as it is written, but also provides documentation for the project, with cross references and even allows for usage samples.

There are no significant differences using javadoc to comment android apps versus any other java code, with one significant exception.

Oracle offers the API overview for java as a javadoc online. You can use this on-line reference to link your code to references when producing javadoc that you publish on-line, as opposed to a local source. However, you can’t use Google’s android reference that way, for their site does not have a package-list nor an index.html file. If you plan to display your javadoc in the Internet, you need a public reference source. To go around this limitation, we must use a different source for the android references. One of the available sources is: http://www.androidjavadoc.com/2.3/. See the Javadoc Generation Configuration (On Eclipse click: Project->Generate Javadoc…) screen shot below.