Get an API Key for Google Map

Before all our work, we first have to apply an API key for Google Maps.

• What is an API key?

An API KEY can be regarded as a kind of authorization mode for interface access.

• How do you get an API key for the Google Maps API?

Google provides developers with an official web page to get an API key with their Google account. You can find that link below:

https://developers.google.com/maps/documentation/android-api/

On the top right of the page, click the “Get a key” button and select “Maps” for  the usage of the API key. You will then get your API key for Google maps.

Create Google Maps Project

1.Download and install Android Studio

As an Android project, developers need to download and install Android Studio as the Android development IDE on PC or Mac. For this Google Maps project, you can keep all the configurations as default.

2.Install Google Play Serve SDK

Google Play Service is required for the Google Map API. We can add the feature via SDK manager (as in the picture below).

3.Create Google Maps Project

Now we have met all the requirements needed to build an Android application with Google Maps. Next we are going to create an Android project in Android Studio. We can choose the “Google Maps Activity” when we create the project. We can also add Google Maps activity whenever we want.

4.Apply the Google Maps Key in our Project

The API key should be added into an XML configuration file. We first go to the manifest, and find this code:

Follow the link “@string/google_maps_key” to “google_maps_api.xml“, and add your KEY in the string part

5.Add permissions

Up to now, if we build and run the project, we will still not be able to see Google Maps on the screen. Before our development, we also need to add at permissions, at least for internet and locations for this project. We can add them in the “Manifest.xml” file.

Now we can see a map loaded in the screen (as the picture below). Tip: we may need VPN access for Google services.

Enable my current location

In the high Android API level, to enable current location, we also need to let the system pop up a message to ask for permission.

Users need to confirm the use their location the first time they open the application. After that, a position button will be shown on the top right of the screen.

Mock location data in Android Studio simulator

In Android Studio, simulators are not able to support the current location. In this case, we need to mutually send the location data to simulators. Android Studio provides a UI interface to do the operation.

As we send the costumed location latitude and longitude to the simulator and click the location button, it is displayed as our current location(mocked).

Set markers in Google Map

Markers will be displayed only after the map has loaded, so we need to implement our codes into “OnMapLoaded” method:

1. Create a new position(s) with longitude and latitude                                                                
2. Add these positions as markers to Google Maps                                                                              
3. Move camera to marker(s)                                                                                                                                                                                      

Get path/route data from Google

Google services provides us with a very strong API for calling. Based on that, we will also be able to display route or even navigation information in our costumed Google Map application. To get route information, developers need to get another Google Map Destination API Key to access the JSON data from Google Direction Service.

1. Get an API key.

This is the same process you used to get a Google Map API key, just link to the address:

https://developers.google.com/maps/documentation/directions/

click the “Get a Key”, button, and just repeat the previous steps.

2. Access Google Direction and get the data from the service.

Now we are able to make a network request to get JSON data from the server. And the base API consists of these parts:

• Base URL

As most of the API, the base URL will almost never be changed or modified when we are calling data from the servers, for now, the base URL is:

https://maps.googleapis.com/maps/api/directions/

• Data format

This part of the the address(pattern) will determine what kind of data file format we will get from the server. Google Direction Services provided us JSON and XML. Here we choose the JSON format.

• Parameters

Parameters contain 2 parts: origin location and destination location. Both of these 2 are required for calling. The format is

?origin=xxx&destination=xxx

• API key

The last part of the address is the API key:

&key=xxxxxxxxxxxx

So, the entire address for calling should look like this:

https://maps.googleapis.com/maps/api/directions/json?origin=XXXXX&destination=XXXX&key=XXXXXXXXXXXXXXXX

• Request data from server and parse JSON data to local module class

This is the last step, developers can choose third-party libraries to load data. Here we choose Retrofit:

As a user

What is TalkBack

Talkback is an Android system accessibility application that was developed by Google official developing team, which has been positioned as to provide special groups of people, like aged or disabled people (especially for blind people) a voice support while they are using Android devices. Once users activate this function in system setting, they can interact with their Android devices conveniently and efficiently via their fingers and ears instead of eyes.

How to activate TalkBack as a normal user

Normally, TalkBack will be default integrated into Android system, and once users need to access the function, they are able to activate it in system settings (Setting -> Accessibility -> Talkback) and costumed their own TalkBack profiles. Users also are recommended to download and install the application as a “.apk” file from Google Play store if their devices’ API level can support TalkBack.

Disadvantages about TalkBack

It is very certain that TalkBack will be a necessary or even required component for some special parts of people. However, because of its working principle, TalkBack also troubled some normal users:

1. TalkBack greatly changed users’ using habit.

For the reason of TalkBack was designed for special groups of people, it has some complex prompt processes to prevent users from misoperations, and in the worst case, TalkBack needs to traverse all the readable widgets to pass information to users via voice. For example, users need to single tap a button to lock on the widget and make sure the widget is a button, and they will need an extra double tapping to execute the button’s function.

2. TalkBack speeds up the consumption of battery level.

A lot of repetitive work, like continuous tapping and speaking, will speed up the consumption of devices’ battery level.

3. Normal users will hard to adapt the different operation mode.

The special working mode will mostly overturn the traditional operation mode for normal user, once users activate the TalkBack inexpertly or accidently, they will find they don’t know even hot to scroll the page from top to bottom without a tutorial.

As a developer

Add accessible support while using system default widgets

Fortunately, all Android system default widgets can support Talkback well, while developers building their applications via these default widgets, usually they don’t need too much code work, once the application is running, the Talkback can recognize and read the text or pre-defined description.

1. Set content description for widgets without readable text in layout XML files.Normally, Talkback can support most of the widgets in Android, but for some special cases, if developers use image views or other widgets without a hint or a line of text, Talkback will have no idea to express the information via voice. So, if need, developers can add a content description for these widgets that Talkback will express special widgets through these description texts.
2. Ignore some unnecessary widgets or items.Sometimes we may expect the Talkback voices not to be so complex, developers can use the “importantForAccessibility” label in XML file to let Talkback ignore some unnecessary widgets, and it could be any readable widgets, like text view or image view.

Add accessible support with Java code (with example)

Here is an example shows the procedure of how to dynamically set the accessibility for Talkback.

The first part of the codes come from the layout XML file, it defined 2 text views to show text label or result and a button that bind with the second text view. Up to now, if we run the application via Talkback, from the 3 screenshots below, we will not difficult to find that the first text view and the button can be marked as green, and we can hear the voice from Talkback, but the second text view (without text label), will not be recognized by Talkback, even it seems in a hidden status and not clickable, but it actually appeared.

And after we add a description in layout xml file:

or in Java code:

the second text view now can be recognized by Talkback and be marked.

Also, if we hope the first text view not be recognized be Talkback, just set the “importantForAccessibility” to “NO” whatever in xml or java source file.

Concepts

What is GitLab

GitLab is a source control platform based on GIT (a free and open source distributed version control system), which can assist developers to manage their codes in a convenient and efficient way.  Normally, through the platform, developers can clearly explore the modification of different version of their codes.

What is GitLab CI

In the latest version of GitLab, a new function as continuous integration server was added. Like most of the CI server, GitLab CI also provided a serious of integration functions such as merging the code, install the dependencies, building, testing and distribution. And developers will no need to install and distribute third-party integration platforms.

Main Procedures

Requirement

Required System Configuration:

• Mac OS X 10.11.3 “El Capitan”
• Xcode version ≥ 7.2
• Xcode iOS Simulator version ≥ 9.2
• Xcode Command Line Tools
• Gitlab.com, version ≥ 8.5

Example System Configuration:

• Mac OS X 10.12.3 “Sierra”
• Xcode Version 8.2.1 (8C1002)
• Xcode iOS Simulator version 10.3
• Xcode Command Line Tool
• Gitlab Community Edition 8.16.4 f32ee82 (update asap)

Create an iOS project with Xcode (use Objective-C as example)

First of all, an iOS project must be created via Xcode (as the pictures shown below).

Add a “.gitlab-ci.yml” file to the root directory of one repository(project).

• File name and extension CANNOT be changed.
• The file will be hidden in Linux & Unix based OS.
• Scripts in the file will be executed after the file has been PUSH to Gitlab with repository.
• The file should be put in the same directory as *. Xcodeproj or *.workspace. Need to be mentioned, once we use some third-party tools (list Cocoapods) to manage third-party tools, a new “.workspace” file will be created.
• Create project with tests (if you would like to add test function for Gitlab multi-runner)

Configuring multiple project-specific Runner(s)

For projects that developed by different programming languages, GitLab CI will not able to directly recognize or execute these codes. So, we need to download and install runners to the operation. Each runner will adapt a kind of programming language, in this example, I choose to download one adapt with Objective-C for iOS projects (also, GitLab CI provided a Swift version).

Each runner can have multi configurations to adapt different requirements of different projects. For example, maybe an iOS project need to support iOS 8 as the lowest supported version, but another one may only need to support the latest version, in this case, we would better make two different configurations for these two projects (although they use the same runner to execute codes). Also, if two projects have the same requirement of CI runner, they can share with the same one. Once a runner is marked as a common/public runner, users will be free to add or remove it in projects.

Requirement(s):

1. Server address & token pair

We need to get a pair of service URL and token to let GitLab CI recognize which project it will bind with, in the next step. The Server address & token will be provided in: “GitLab project webpage -> settings -> CI/CD pipelines”

2.Install GitLab Runner [Mac OS X – iOS]:

We can use the “Terminal” application to do the operations in Max OS X.

• Download the binary for your system (here provided Objective-C and Swift version)
• Register the runner                                 
• Install runner as service and start it    

Edit the “.yml” file

Normally, three main processes will be added to job queue into the “.yml” file for integration: build, test and deploy.

Build: Once developers upload new versions of code into the GitLab, the GitLab CI will automatically build the project that makes sure the project is buildable.

Test: The test job can run the unit tests and UI tests automatically; the premise is that users add tests scheme in projects and configured it in the “.yml” file.

Deploy: The runner can deploy an executable file as a zipped file in CD/CI Pipeline page. Normally, users can directly download it via web browsers.

Here is an module configuration of “.yml” file.

Commit and push commits to Gitlab

After we have done all the previous steps, we will able to push our code to GitLab, and GitLab will call it’s CI service to do the integration automatically.

View status on web page

The last step is to view the result of the auto integration, we can see them in the “pipeline” page.