The Pocket Science Lab Android app has various functionalities which have been already implemented but it been on the verge of development, many functionalities are yet to be implemented completely, one such functionality is how the users report the issues of the app, to which comes the idea of using a Google form inside the app for the users to fill it and the issue get directly opened in Github.
Submitting a Github issue through a Google forms requires two things:-
A Github access token which gives access to open a new issue.
To generate a Github access token one must follow these steps[2]
Go to the personal settings.
Select Developers settings option from it.
In Developers settings option Go to personal access tokens and generate an access token.
A fully-structured Google form which has all the details about the issue i.e the title of the issue, the body of the issue, label, etc..
Using a Google account create a Google Form which have all the relevant questions about that issue such as title of the issue, body of the issue, label etc..
Once done with all the steps follow these steps to send a Github issue[1]
Click the Responses tab, in it click the More icon.
Select Choose a response destination.
Select New spreadsheet: Creates a new spreadsheet in Google Sheets for responses.
Click Create to create and open the sheet.
Configure the App Script Logic[1]
You should have a newly created blank spreadsheet with headers automatically generated from your form.
Click Tools > Script editor… to launch the App Script editor coding environment. This Script will be bound to your sheet, so you can listen for form submissions and fire off a new issue to your GitHub repo.
In the script editor write the following code
function onFormSubmit(e) {
vartitle = e.values[1];
var body = e.values[2];
varlabel = "User opened issue"var payload = {
"title": title,
"body": a_body,
"label": label,
};
var options = {
"method": "POST",
"contentType": "application/json",
"payload": JSON.stringify(payload)
};
var response = UrlFetchApp.fetch("https://api.github.com/repos/abhinavraj23/AgeGroup/issues?access_token="+ghToken, options)
}
Note:The onFormSubmit function includes an event object e, which includes the form/spreadsheet field values as a simple array with values in the same order as they appear in the spreadsheet. e.values[0] is the first spreadsheet column
The following google-app script uses GitHub Issues API for posting a new issue in Github.
4.Give your app script project a name and save it .
Set up the Trigger[1]
From within the app script editor, click Resources > Current project’s triggers.
Click to add a trigger
Run: onFormSubmit
Events: From spreadsheet, On form submit
Click Save and accept any authorizations to access your forms and access web services on your behalf.
This trigger will listen to form submissions and pass the data to your function, which POSTs the new issue to your GitHub repo.
Thus using these steps one can submit an issue in github through a Google Form and thus the Google Forms can be used in the app as the users can send the issues using a google form, and through this method one can also get the email-id of the user for further contact and thus this is a very useful method.
The PSLab android app consists of different instruments like oscilloscope, multimeter, wave generator etc and each instrument has different functionality and usage so it is necessary that there should be an instruction guide for every instrument so that the user can easily read the instruction to understand the functionality of the instrument.
In this we will create an instruction guide for the Wave Generator which will contain information about the instrument, it’s functionalities, steps for how to use the instrument.
The main component that I used to create instruction guide is Bottom Sheet. Bottom Sheet is introduced in Android Support v23.2 . It is a special UI widget which slide up from the bottom of the screen and it can be used to reveal some extra information that we cannot show on the main layout like bottom menus, instructions etc.
They are of two types :
Modal Bottom Sheet:– This Bottom Sheet has properties very similar to normal dialogs present in Android like elevation only difference is that they pop up from the bottom of screen with proper animation and they are implemented using BottomSheetDialogFragment Class.
Persistent Bottom Sheet:– This Bottom Sheet is included as a part of the layout and they can be slid up and down to reveal extra information. They are implemented using BottomSheetBehaviour Class.
For my project, I used persistent Bottom Sheet as modal Bottom Sheet can’t be slid up and down by the swipe of the finger whereas persistent Bottom Sheet can be slid up and down and can be hidden by swipe features.
Implementing the Bottom Sheet
Step 1: Adding the Dependency
To start using Bottom Sheet we have to add the dependency (We have also include Jake Wharton-Butterknife library for view binding but it is optional.)
In this step, we will create the layout of the Bottom Sheet, as our purpose of making Bottom Sheet is to show extra information regarding the instrument so we will include ImageView and TextView inside the layout that will be used to show the content later.
Some attributes in the layout worth noting are:
app:layout_behavior: This attribute makes the layout act as Bottom Sheet.
app:behavior_peekHeight: This is the height of the Bottom Sheet when it is minimized.
app:behavior_hideable: Defines if the Bottom Sheet can be hidden by swiping it down.
Here, we will also create one extra LinearLayout having height equal to the peek_height. This LinearLayout will be at the top of the BottomSheet as shown in Figure 1 and it will be visible when the BottomSheet is in a minimized state(not hidden). Here we will put text view with like “Show guide” and an arrow pointing upwards so that it is easier for the user to understand that sheet can be viewed by sliding up.
Figure 1 LinearLayout containing textview and imageview
Here is the gist[2] that contains code for the layout of the Bottom Sheet guide
After this step, we can see a layout of Bottom Sheet in our Android Editor as shown in Figure 2
Figure 2 shows the layout of the Bottom Sheet
Step 3: Creating the Container view layout containing content and Bottom Sheet
For container view, we will create new layout under Res⇒Layout and name it “container_view_wavegenerator.xml”
In this layout, we will use ‘Coordinator Layout’ as ViewGroup because persistent Bottom Sheet is implemented using BottomSheetBehavior class which can only be applied to the child of ‘CoordinatorLayout’.
Then add the main layout of our instrument and the layout of the Bottom Sheet inside this layout as its child.
Step 4: Setting Up Bottom Sheet and Handling callbacks
Now we will head over to the “WaveGenerator.java” file(or any instrument java file). Here we will handle set up Bottom Sheet and handle callbacks by using following classes:
BottomSheetBehavior provides callbacks and makes the Bottom Sheet work with CoordinatorLayout.
This method is called when the Bottom Sheet slides up and down on the screen. It has slideOffset as a parameter whose value varies from -1.0 to 0.0 when the Bottom Sheet comes from the hidden state to collapsed and 0.0 to 1.0 when it goes from collapsed state to expanded state.
publicvoid onStateChanged(@NonNull View bottomSheet, int newState)
This method is called when BottomSheet changed its state. Here, let us also understand the different states which can be attained by the Bottom Sheet:
BottomSheetBehavior.STATE_EXPANDED : When the Bottom Sheet is fully expanded showing all the content.
BottomSheetBehavior.STATE_HIDDEN : When the Bottom Sheet is hidden at the bottom of the layout.
BottomSheetBehavior.STATE_COLLAPSED : When the Bottom Sheet is in a collapsed state that is only the peek_height view part of the layout is visible.
BottomSheetBehavior.STATE_DRAGGING : When the Bottom Sheet is dragging.
BottomSheetBehavior.STATE_SETTLING : When the Bottom Sheet is settling either at expanded height or at collapsed height.
We will implement these methods in our instrument class, and also put the content that needs to be put inside the Bottom Sheet.
In the blog Creating the onScreen Monitor Using CardView I had created the monitors to view the wave properties in this blog we will create the UI of controlling panel that will be used for that monitors with multiple buttons for both analog and digital waveforms.
Which layout to choose?
In today’s world, there are millions of Android devices present with different screen sizes and densities and the major concern of an Android developer is to make the layout that fits all the devices and this task is really difficult to handle with a linear or relative layout with fixed dimensions.
To create a complex layout with lots of views inside the parent using linear layout we have to make use of the attribute layout_weight for their proper stretching and positioning, but such a complex layout require a lot of nesting of weights and android tries to avoid it by giving a warning :
Nested Weights are bad for performance
This is because layout_weight attribute requires a widget to be measured twice[1]. When a LinearLayout with non-zero weights is nested inside another LinearLayout with non-zero weights, then the number of measurements increases exponentially.
So, to overcome this issue we will make use of special type of layout “Constraint Layout” which was introduced in Google I/O 2016.
Features of Constraint Layout:-
It is similar to Relative Layout as all views are laid out according to their relationship with the sibling, but it is more flexible than Relative Layout.
It helps to flatten the view hierarchy for complex layouts.
This layout is created with the help of powerful tool provided by Android which has a palette on the left-hand side from where we can drag and drop the different widgets like TextView, ImageView, Buttons etc. and on the right-hand side it provides options for positioning, setting margins and other styling option like setting color, change text style etc.
It automatically adjusts the layout according to the screen size and hence doesn’t require the use of layout_weight attribute.
In following steps, I will create the controlling panel for Wave generator which is a complex layout with lots of buttons with the help of constraint layout.
Step 1: Add the dependency of the Constraint Layout in the Project
To use Constraint layout add the following to your build.gradle file and sync the project
Guidelines[3] are anchors that won’t be displayed in your app, they are like one line of a grid above your layout and can be used to attach or constraint your widgets to it. They are only visible on your blueprint or preview editor. These will help to position and constraint the UI components on the screen easily.
For adding guidelines :
As shown in Figure 1 Right-click anywhere on the layout -> Select helpers -> Select horizontal or vertical guideline according to your need.
Figure 1 shows the horizontal guideline being added to the layout.
And for positioning the guideline we have to set the value of attribute layout_constraintGuide_percent
Let’s say we want the guideline to be at the middle of the screen so we’ll set :
app:layout_constraintGuide_percent=”0.50″
For my layout I have added three guideline :
One horizontal guideline at 50%
Two vertical guidelines at 30% and 65%
Doing this will bifurcate the screen into six square blocks as shown in below figure :
Figure 2 shows the blueprint of constraint layout containing two vertical and one horizontal guidelines with their percentage offset from respective bases
Step 3: Adding the buttons in the blocks
Until now we have created six squares blocks, now we have to put a button view in each of the boxes.
First drag and drop button view from the Palette (shown in Figure 3) on the left side inside the box. Figure 3 shows the layout editor palette
Then we have to set constraints of this button by clicking on the small circle present on the middle of edges and dragging it onto the side of the block facing it. Figure 4 shows the button widget getting constrained to sides
Set the layout_width and layout_height attribute of the button to be “0dp”, doing this the button will expand in all the direction occupying all the space with respect to the border it has been constrained with.
Figure 6 shows the button widget expanding to all the available space in the box
Similarly, adding buttons in all the square blocks and providing proper theme color we will have a blueprint and layout as shown in Figure 6.
Figure 6 shows the waveform panel blueprint and actual layout for analog waves with six buttons
Following the same steps until now, I have created the other controlling panel layout having buttons for digital waves as shown in Figure 7
Figure 7 shows other constraint layout for digital waves having seven buttons
Detailing and combining the panels to form Complete UI
After adding both the panels we have created in this layout inside the Wave Generator we have the layout as shown in Figure 8
Figure 8 shows the UI of Wave Generator as shown by a actual Android device in the PSLab app.
As we can see on adding the panels the button created inside the layout shrink so as to adapt to the screen and giving out a beautiful button-like appearance.
It’s pretty common to face connectivity issues and when the user has no Internet connection he should be shown an appropriate response rather than allowing him to send requests to the server. Let’s have a look how we are handling such cases in Open Event Android
Firstly we need to add the required permission in the manifest. We need the permission to access the user’s WiFi state and network state.
We use this function to check if the user is connected to the Internet. This function return a Boolean which is true if the user is connected to the Internet otherwise it is false
This function is used to decide which screen should be shown to the user. If the user has an active Internet connection he will see events fragment but if there is no Internet he will see the no Internet card.
privatefunshowNoInternetScreen(show: Boolean) {
rootView.homeScreenLL.visibility = if (show) View.VISIBLE else View.GONE
rootView.noInternetCard.visibility = if (!show) View.VISIBLE else View.GONE
}
Let’s see how the above two functions are used in the events fragment. When the app starts we check if there is a need to show the no Internet screen. If the user is not connected to the Internet, the no Internet card will be shown. Then when the user clicks on retry, the events fragment is shown again if the user is connected to the Internet.
Let’s have a look a how the XML code looks, here we are only seeing a part of the code as the rest is pretty obvious. We have cardView and inside it all the views ie ImageView,TextView are inside a LinearLayout which has a vertical orientation so that all these views appear below each other.
In the Open Event Android App there is a section called “Manage events”, we direct the users to the Organizer’s app if the users have the app already installed otherwise we open the organizer’s app in the playstore. This way users are motivated to create events using the organizer’s app. Let’s see how this feature was implemented.
So when the user clicks on the menu item “Manage Events” startOrgaApp function is called with the package name of the organizer’s app as the argument. Android apps are uniquely identified by their package names in the playstore.
Let’s have a look at the startOrgaApp function that we are calling above. We are using a try/catch block here. We are opening the app in the try block if it is installed otherwise we throw ActivityNotFoundException and if this exception happens we will catch it and use the showInMarket function to show the Organizer’s app in the market.
Now since we know this will never raise an exception there is no try catch block as the app with this package name will always be there. We just need to create an intent with the required parameters and then just pass the intent to startActivity
Lastly we just need to add the XML code to create a menu item. It should contain the id so that we can reference it and the title that will be visible.
In this blog, we will create the monitor screen in the PSLab Android app using Android studio.
Deciding the layout to use for monitors
As monitors with rounded border look appealing on android device screen so we will select CardView to be the base layout of our monitors. The CardView element allows us to add certain properties like rounded corners, elevation etc.
To use the CardView in your app, add the following dependency to build.gradle file and sync the project.
Add the <android.support.v7.widget.CardView> widget to your layout and all the other views to be shown on monitor screen will be placed inside this card layout as its child layout.
Creating the monitor cards
We need to decide how much spacing is to be provided to the cards to properly view them on different screens. Here we make use of the special attribute in the View class.
android:layout_weight=1
This attribute assigns an “importance” value to a View in terms of how much space it should occupy on the screen. That is if we give equal weight to two views which inside the same parent then they will both occupy equal space.
To implement this create two CardViews inside <LinearLayout> with the same layout_weight.
So this will give us a screen like this with equally weighted monitor card views as shown in Figure 1.
Figure 1 shows two CardView with equal weights(w/2) and equal width
Both the cards have the width equal to half the screen width which is set automatically by the Android.
Creating partitions in the monitors
We have to make partitions in the monitor screen so that every characteristic of Wave Generator like wave frequency, phase, selected pin etc. can be viewed simultaneously on the screen with proper spacing.
For making partitions we need to make a separator line which we can create by using <View> and setting the attributes as below:
This will create a thin line having the grey color. We have to make four partitions of the card view for both monitors as shown in Figure 2.
Figure 2 shows two monitors with line separator making partitions
Populating the screen with text and image icons
We have to include the <TextView> and <ImageView> to show the property data on the monitors.
Figure 3 shows partitions in the monitor CardView
Different partitions as shown in Figure 3 can be used for showing different data such as:
Top Partition:- To view the selected wave.
Left Partition:- To view the selected waveform eg:- sine, triangular
Right Partition:- To view the selected wave characteristics like frequency, phase etc.
Bottom Partition:- To view the property selected which has been selected by user
After inserting all the desired Views and providing the Views with dummy data and icons and customizing the Views by giving proper color and spacing finally we will have a layout as shown in Figure 4.
Figure 4 shows ImageView and TextView showing different dummy data
In Figure 4, the left CardView shows all the properties for the Analog Wave Generator and the right CardView shows all the properties for Digital Wave Generator.
All the characteristics on the monitors can be controlled by the controlling panel which is work in progress.
PSLab Android app by FOSSASIA provides a variety of features to its users. One of them is accessing various types of sensors both built into mobile phone and external sensors connected with PSLab device. In earlier versions users were only able to view the captured data. Moving forward, adding improvements to the app, now there is a feature to save those data displayed in graphs in csv format.
This feature is important in many ways. One is educational. In a classroom, teachers can ask students to perform an experiment and prepare a report using the data collected. By just visualizing they cannot do this. Actual data points must be made available. Another use is sharing data sets related to say environmental data over different demographics.
CSV, or comma-separated values file is a text file where stored data are separated by commas. The file stores these tabular data (numbers and text) in plain text format. Each line of the file represents a data record. Each data record consists of one or more fields, separated by commas. CSV files are commonly used to store sensor data because of its easy use. This post is about how PSLab device uses CSV file to write sensor data in it.
In PSLab android source code, there is a dedicated class to handle read sensor data from different instruments called “CSVLogger”. Developers can easily instantiate this class wherever they want a data logging as follows;
This will create a blank folder in “PSLab” folder in device storage. The CSV file is generated with the following convention according to the date and time where data is saved in the file.
yyyymmdd-hhmmss.csv
A sample file would have a name like 20180710-07:30:28.csv inside the SUBFOLDER which is specific to each instrument. Folder name will be the one used when initiating the CSVLogger.
With this method, logging data is pretty easy. Simply create a string which is a comma seperated and ended with a new line character. Then simply call the writeCSVFile(data) method with the string as a parameter added to it. It will keep appending string data until a new file is created. File creation can be handled by developers at their own interests and preferences.
To bring out an example let’s view how it’s implemented in Lux Meter instrument. This is a good source one can refer to when adding this feature in fragments
inside a main activity. In Lux Meter, there is the parent activity named Lux Meter and inside that there are two fragments, one is fragmentdata and the other one is fragmentsettings. Data capturing and saving occurs inside fragmentdata.
Menu icon controlling happens in the parent activity and we have bound a variable across the main activity and child fragment as follows;
LuxMeterActivityparent=(LuxMeterActivity)getActivity();if(parent.saveData){/* Save Data */}
This makes it easier listening menu icon clicks and start/stop recording accordingly. How to handle menu icons is beyond the scope of this blog and you can find tutorials on how to do that in the Resources section at the bottom of this blog post.
Once these CSV files are available, users can easily integrate them with advanced software like Matlab or Octave to do further analysis and processing to captured data sets.
The first thing that was implemented in the Open Event Android app was the login screen. This is because there were many API endpoints which cannot be accessed without an auth token. Let’s see how this was implemented.
JWT token
Firstly let’s talk about what is this token that I mentioned. The token is JWT (Javascript Web Token) which includes certain information about the user, such as identifier and information about if the token is valid, when will it expire and a signature to verify if it was tampered.
Code
Let’s have a look at the code in the Login fragment. Firstly we have a boolean to check if the user should login or not. If this variable is true we will send the user to the MainActivity. Next if the user clicks on the login button we will check the username and password and then the we will decide whether to show the progress bar or not. If the user encounters an error while logging in that error is shown to the user in a toast message.
All these methods and variables are declared in the ViewModel so let’s have a look there to understand them. All our variables are of the type LiveData, this is the reason why we are using the observe method in the login fragment. The observe method is used to observe these variables and whenever their value is changed it notifies the observer. In the login function we are sending a request to the server in a background thread.
val progress = MutableLiveData<Boolean>()
val error = SingleLiveEvent<String>()
val loggedIn = SingleLiveEvent<Boolean>()
fun isLoggedIn() = authService.isLoggedIn()
fun login(email: String, password: String) {
if (email.isNullOrEmpty() || password.isNullOrEmpty()) {
error.value = “Unable to Login. Please check your credentials”
}))
}
Finally lets have a look at the login function of the AuthService class that was used above. We will throw an exception if the username or password is empty. Otherwise we will send a POST request to the server with the username and password. Then we will store the JWT access token which will be used when we will access the endpoints of the server.
fun login(username: String, password: String): Single<LoginResponse> {
if (username.isEmpty() || password.isEmpty())
throw IllegalArgumentException(“Username or password cannot be empty”)
return authApi.login(Login(username, password))
.map {
authHolder.token = it.accessToken
it
}
}
This is how the POST request for login looks
@POST(“../auth/session”)
fun login(@Body login: Login): Single<LoginResponse>
This all that is required to create the login fragment.
In the Phimpme Android application, the images are displayed in the albums in which they are indexed in the device’s storage. However, there is also an “All photos” section in the application where all the images present in the device’s storage are displayed at once irrespective of the folder they’re indexed in. So in this post, I will be discussing how we achieved the “All Photos” functionality.
Android framework provides developers with a media content provider class called MediaStore. It contains metadata for all available media on both internal and external storage devices. With the help of particular methods we can obtain metadata for all the images stored in the device’s storage.
Step 1
So First we need to get the Uri from MediaStore content provider pointing to the media(here media refers to the photos stored on the device). This can be done by the following snippet of code.
Uri uri = android.provider.MediaStore.Images.Media.EXTERNAL_CONTENT_URI;
Step 2
Now retrieving a cursor object containing the data column for the image media is required to be performed. The data column will contain the path to the particular image files on the disk. This can be done by querying the MediaColumns table of the MediaStore class, which can be performed by the use of the content resolver query method. The mentioned functionality can be achieved by the following lines of code.
In the final step, we would retrieve the path of all the images by iterating through the cursor object obtained in the previous step and keep adding those paths to an ArrayList<String>. Creating Media objects passing in the image path and concurrently adding those Media objects to an ArrayList<Media> to be done thereafter. Finally, the dataset(ArrayList<Media> in this case) containing Media objects for all the images is required to be passed to the Media Adapter in order to display all the photos in the UI. The code snippets used for the final steps are provided below.
while (cursor.moveToNext()) { absolutePathOfImage = cursor.getString(cursor.getColumnIndexOrThrow(MediaStore.MediaColumns.DATA)); listOfAllImages.add(absolutePathOfImage); }
This is how we achieved the functionality to display all the images from the storage on a single screen(at once) in the Phimpme Android application. To get the full source code, please refer to the Phimpme Android Github repository listed in the resource section below.
The screenshot for displaying the “All photos” section is provided below.
SharedPreferences is used in android to store data in the form of a key-value pair in an application. But, sometimes we need to store data at many places in the application such as saving the login email or a particular information that remains the same for the entire use of the app. In SUSI.AI android app PrefManager.java class is made that uses the sharedpreferences in android and provides a custom wrapper that is used to store the data in the key-value pair form in the app.
To store data in sharedpreferences through the PreferenceManager class we just need to declare an instance of the PreferenceManager in the location in which we want to save the data. The SUSI.AI Android app opens up the login screen and on just viewing the welcome cards for the first time due to the incorrect implementation of the sharedpreferences, using the Preference Manager we can correctly implement the preferences in welcome activity.
Whenever we install the SUSI.AI Android app, on opening it for the first time we see welcome cards that give a basic overview of the app. So, now after swiping all the cards and on reaching the final card instead of clicking GOT IT to move to the login screen and on pressing the home button we put the app in the background. Now, what happened was when the app showed cards, it was due to the WelcomeActivity.java activity.
In the onCreate() method of this activity we check whether the WelcomeActivity is opened for the first time or not. In this case we make use of the PrefManager.java class.
if (PrefManager.getBoolean(“activity_executed”, false)) { Intent intent = new Intent(this, LoginActivity.class); startActivity(intent); finish(); } else { PrefManager.putBoolean(“activity_executed”, true); }
This piece of code calls the getBoolean(<preferenceKey>,<preferenceDefaultValue>) of the PrefManager.java class and checks the boolean value against the preference key passed in the function.
If it is the first time when this function is called then the default value is accessed against the preference key: “activity_executed”, which is passed as false and no code within the if statement is executed and so the code in the else block is executed which puts the value true as the preference value against the key “activity_executed” and the next line is executed in the sequence after this line. In short, on opening the app for the first time the preference key “activity_executed” has a value of true against it.
When we close the app by destroying it while it is in the WelcomeActivity, the onDestroy() method is called and memory is cleared, but when we open the app again we expect to see the Welcome Cards, but instead we find that we are on the login screen, even though the GOT IT button on the final card was not pressed. This is because when we go through the onCreate() method again the if condition is true this time and it sends the user directly to the Login activity.
To, solve this problem the method that was followed was :
Remove the else condition in the if condition where we check the value stored against the key “activity_executed” key.
In the onCreate() method of the LoginActivity.kt file use the PrefManager class to put a boolean value equal to true against the key : “activity_executed”.So the code added in the LoginActivity.kt file’s onCreate() method was :
PrefManager.putBoolean(“activity_executed”, true)
Also, the else condition was removed in the Welcome activity. Now, with these changes in place unless we click GOT IT on the final card in the welcome activity we won’t be able to go to the Login Activity, and since we won’t be able to go to the final activity the value against the key “activity_executed” will be false. Also, once we move to the login activity we will not be able to see the cards as the if condition described above will be true and the intent will fire the user to the Login Activity forever.
Therefore, using the PrefManager class it became very easy to put values or get values stored in the sharedpreferences in android. The methods are created in the Preference manager for different types corresponding to the different return types present that can be used to store the values allowed by the SharedPreferences in Android.
Using the PrefManager class functions it was made easy in SUSI.AI android app to access the SharedPreferences and using it a flaw in the auth flow and opening of the app was resolved.
You must be logged in to post a comment.