Compress Images Size in Phimpme Android application

In the Phimpme Android application, users can perform various operations on images such as editing an image, sharing an image, moving the image to another folder, printing a pdf version of the image and many more. However, another important functionality that has been implemented is the option to compress an image. Two modes of compress operation have been implemented namely compress by size and compress by dimensions. So in this blog post, I will be discussing how we achieved the functionality to compress any image by size.

Step 1

First, we need to add an option in the bottom bar menu(in the SingleMediaActivity) to compress the image being viewed. The option to compress an image has been added by implementing the following lines of code in the  menu_bottom_view_pager.xml file.

<item
      android:id=“@+id/action_compress”
      android:orderInCategory=“2”
      app:showAsAction=“always”
      android:icon=“@drawable/compressicn”
      android:title=“Compress”/>

Step 2

Now on selecting the compress option, the user would be prompted to choose the compress mode i.e compress by size or compress by dimension. Once the user has opted for the size mode a dialog with a seekbar to set the compress percentage is to be displayed. Code snippets used to implement the dialog along with seekbar is displayed below.

<RelativeLayout
  android:layout_width=“wrap_content”
  android:layout_height=“wrap_content”
  android:layout_marginTop=“8dp”>

  <SeekBar
      android:id=“@+id/seekBar”
      android:layout_width=“match_parent”
      android:layout_height=“wrap_content”
      android:layout_weight=“0.65”
      android:max=“90”
      android:progressBackgroundTint=“@color/colorPrimary”
      android:thumb=“@drawable/ic_location_on_black_24dp” />

  <TextView
      android:id=“@+id/textview2”
      android:layout_width=“wrap_content”
      android:layout_height=“wrap_content”
      android:layout_alignParentEnd=“true”
      android:layout_below=“@+id/seekBar”
      android:layout_marginBottom=“5dp”
      android:layout_marginEnd=“16dp”
      android:text=“95%”
      android:textAppearance=“@style/TextAppearance.AppCompat.Body1”
      android:textSize=“16sp” />
</RelativeLayout>

A screenshot displaying the dialog to set the compress percentage is provided below

Step 3

Here to obtain the compress functionality we have used an open-sourced custom image compression library Compressor. After the user has set the compress percentage, the Compressor class of the library is instantiated by passing-in the context as the parameter and some of its functions are invoked simultaneously. The functions invoked are setQuality(), setCompressFormat(), setDestinationDirectoryPath(), compressToFile().

setQuality(int) – to set the percentage compressed.

setCompressFormat(Bitmap.CompressFormat) – to determine the format of the output compressed image.

setDestinationDirectoryPath(File) – to specify the path to which the compressed image is to be saved.

compressToFile(File) – to perform the compress operation, passing-in the file object of the corresponding image to be compressed.

The compressToFile() function performs the final compress operation and saves the compressed image to the specified path.

Code snippets to implement the above-mentioned operations are given below

private void compressSize() {

  LayoutInflater inflater = getLayoutInflater();
  View dialogLayout = inflater.inflate(R.layout.dialog_compresssize, null);
  TextView title = (TextView) dialogLayout.findViewById(R.id.compress_title);
  title.setBackgroundColor(getPrimaryColor());
  SeekBar percentsize = (SeekBar) dialogLayout.findViewById(R.id.seekBar);
  percentsize.getThumb().setColorFilter(getAccentColor(), PorterDuff.Mode.SRC_IN);
  percentsize.setProgress(0);
  final TextView percent=(TextView)dialogLayout.findViewById(R.id.textview2);
  percentsize.setOnSeekBarChangeListener(new SeekBar.OnSeekBarChangeListener() {
      @Override
      public void onProgressChanged(SeekBar seekBar, int progress, boolean fromUser) {
          //options of compress by size from 5% to 9;
          int progress1=95-progress;
          progress1=progress1-progress1%5;
          percent.setText(progress1+“%”);
          percentagecompress=progress1;}

      @Override
      public void onStartTrackingTouch(SeekBar seekBar) {
          //do nothing
      }

      @Override
      public void onStopTrackingTouch(SeekBar seekBar) {
          //do nothing
      }
  });}
new Compressor(getApplicationContext())
.setQuality(percentagecompress)
.setCompressFormat(Bitmap.CompressFormat.JPEG)
.setDestinationDirectoryPath(FileUtilsCompress.createFolders().getPath())
.compressToFile(new File(saveFilePath));

This is how we have implemented the functionality to compress an image by size in the Phimpme Android application. To get the full source code, please refer to the Phimpme Android Github repository.

Resources

  1. Android Developer documentation –https://developer.android.com/reference/java/io/File
  2. Compressor Library – https://github.com/zetbaitsu/Compressor
  3. Seekbar Tutorial – https://abhiandroid.com/ui/seekbar
Continue ReadingCompress Images Size in Phimpme Android application

Implementing Undo Operation in Phimpme Android application

In the Phimpme Android application, users can perform various operations on the images available including renaming an image, sharing images, deleting images from the storage etc. However, there might occur a scenario where the user accidentally or in a rush performs some action and would want to undo it the very next second, so in such cases the undo action feature comes in pretty handy. So in this blog post, I will be discussing the undo operation option implemented for the delete image feature in Phimpme Android app.

Step 1

Firstly, we need to add an “Undo” action button in the Snackbar that displays the success operation message. With this addition, the user would have time to undo an operation until the snackbar message is being displayed on the screen. The undo action button can be added to the Snackbar by the use of the setAction method of the Snackbar class. The code snippets used to implement the button is provided below

Snackbar snackbar = SnackBarHandler.showWithBottomMargin2(mDrawerLayout, String.valueOf(no) + ” “ + getString(R.string
              .trashbin_move_onefile),
      navigationView.getHeight
              (), Snackbar.LENGTH_SHORT);
snackbar.setAction(“UNDO”, new View.OnClickListener() {
  @Override
  public void onClick(View view) {
      getAlbum().moveAllMedia(getApplicationContext(), getAlbum().getPath(), media1);
      refreshListener.onRefresh();
  }
});
snackbar.show();

Step 2

When the user performs the delete operation, first the photos are moved to the trashbin and the user have the option to delete them from there. Now, if the user opts for undo operation, on clicking the undo button the function moveallMedia will be invoked passing-in context, the path of the current album and an ArrayList<Media> containing the deleted media on which the undo operation is to be performed upon, as parameters. Here the ArrayList<Media> passed as a parameter contains the trashbin paths of the images deleted by the previous action. A method storeDeletedFilesTemporarily has been used that returns the list containing the deleted images trashbin paths. The implementation of the method storeDeletedFilesTemporarily has been provided below.

private ArrayList<Media> storeDeletedFilesTemporarily(){
ArrayList<Media> deletedImages = new ArrayList<>();
if(!all_photos && !fav_photos && editMode){
for(Media m: getAlbum().getSelectedMedia()){
String name = m.getPath().substring(m.getPath().lastIndexOf(“/”) + 1);
deletedImages.add(new Media(Environment.getExternalStorageDirectory() + “/” + “.nomedia” + “/” + name));
}
} else if(all_photos && !fav_photos && editMode){
for(Media m: selectedMedias){
String name = m.getPath().substring(m.getPath().lastIndexOf(“/”) + 1);
deletedImages.add(new Media(Environment.getExternalStorageDirectory() + “/” + “.nomedia” + “/” + name));
}
}
return deletedImages;
}

Step 3

Now in the final step, I’d discuss the implementation of the moveAllMedia method that actually completes the undo operation. As I mentioned earlier that on performing the delete operation the images are moved to the bin folder(which is hidden from the other applications), so the moveAllMedia method here will again move the images from the trashbin folder to the current folder. With this operation deleted images would be stored back to their original folder and their trashbin record would be simultaneously deleted from the Realm database. The code implementation of the moveAllMedia method is provided below.

public int moveAllMedia(Context context, String targetDir, ArrayList<Media> albummedia){
 int n = 0;
 try
 {
    int index=-1;
    for(int i =0;i<albummedia.size(); i++)
    {
       String s = albummedia.get(i).getPath();
       int indexOfLastSlash = s.lastIndexOf(“/”);
       String fileName = s.substring(indexOfLastSlash + 1);

       if(!albummedia.get(i).getPath().equals(targetDir+“/”+fileName)){
          index=-1;
       }else{
          index=i;
          break;

       }
    }
    if(index!=-1)
    {
       n = –1;
    }else{
       for (int i = 0; i < albummedia.size(); i++) {

          if (moveMedia(context, albummedia.get(i).getPath(), targetDir)) {
             String from = albummedia.get(i).getPath();
             scanFile(context, new String[]{ from, StringUtils.getPhotoPathMoved(albummedia.get(i).getPath(),
                   targetDir) },
                   new MediaScannerConnection.OnScanCompletedListener() {
                      @Override
                      public void onScanCompleted(String s, Uri uri) {
                         Log.d(“scanFile”, “onScanCompleted: “ + s);
                      }
                   });
             media.remove(albummedia.get(i));
             n++;
          }
       }
       setCount(media.size());
    }
 } catch (Exception e) { e.printStackTrace(); }
 return n;

}

This is how we have implemented the functionality to perform Undo operation in the Phimpme Android application. To get the full source code, please refer to the Phimpme Android Github repository.

Resources

  1. Android Developer documentation –https://developer.android.com/reference/java/io/File
  2. MediaScanner Tutorial – https://stackoverflow.com/questions/9414955/trigger-mediascanner-on-specific-path-folder-how-to/25086535

 

Continue ReadingImplementing Undo Operation in Phimpme Android application

Option to Restore Deleted Images in Phimpme Android Application

In the Phimpme Android application, users can perform various operations on the images including renaming an image, sharing images, deleting images from the storage etc. However with the implementation of Trash Bin feature in the app, the user is now provided with the option to restore back the deleted images. Whenever the delete operation is performed, the selected images are moved to the Trash Bin and the user has the option to either delete the photos permanently or restoring back the deleted photos by navigating to the Trash bin section. So, in this post I’d be discussing the implementation of restore image/images functionality.

Step 1

Firstly, we need to add restore option in the popup menu provided in the itemview in the TrashView section. Every item in the Trashbin section displays a popup menu with two options-restore and delete permanently. The popup menu along with the two options have been implemented by adding the following lines of code.

<?xml version=“1.0” encoding=“utf-8”?>
<menu xmlns:android=“http://schemas.android.com/apk/res/android” xmlns:app=“http://schemas.android.com/apk/res-auto”>

<item
    android:id=“@+id/restore_option”
    android:title=“@string/restore_photo”
    app:showAsAction=“never” />

<item
    android:id=“@+id/delete_permanently”
    android:title=“@string/delete_permanently”
    app:showAsAction=“never” />
</menu>

Step 2

Now after the user opts to restore a particular image, the corresponding realm object for the image would be retrieved from the Realm database. This realm object would contain attributes namely trashbinpath, oldpath, datetime, timeperiod. Here the oldpath attribute contains the path where it  was stored in the device storage before the delete operation was performed on the image. Thereafter to restore the image to its old path, a move operation would be performed which would move the image from the TrashBin section to the album it was stored in before deletion. With this move operation, the image is restored to its old path and is visible in the respective album resulting in the removal/deletion of the image from the TrashBin section. The method implemented to perform the above mentioned operations is provided below.

private boolean restoreImage(TrashBinRealmModel trashBinRealmModel){
  String oldpath = trashBinRealmModel.getOldpath();
  boolean success = false;
  try {
      String from = trashBinRealmModel.getTrashbinpath();
      if (success = moveMedia(context, from, targetDir)) {
          scanFile(context, new String[]{ from, StringUtils.getPhotoPathMoved(pathofmed, targetDir) });
      }
  } catch (Exception e) { e.printStackTrace(); }
  return success;
}

Step 3

In the previous step, the move operation for the restore feature was performed by the restoreImage method which inturn uses method moveMedia() to get the job done. So in this step, I’d be discussing about the implementation of the moveMedia() method. Inside the moveMedia() method, moveFile method of ContentHelper class is invoked passing-in context, sourcefile, and the destination folder as the parameters. Thereafter a normal rename operation is performed by the use of the renameTo method to move the file to destination folder. Now if the rename operation is performed successfully, the file is moved to its old path whereas if the rename operation fails to get the job done, a copy operation is initiated to copy the file to the destination folder and the image  the is deleted from the trashbin section if the copy operation is successful. The code snippets used to implement the moveMedia and moveFile are provided below.

private boolean moveMedia(Context context, String source, String targetDir) {
 File from = new File(source);
 File to = new File(targetDir);
 return ContentHelper.moveFile(context, from, to);
}
public static boolean moveFile(Context context, @NonNull final File source, @NonNull final File targetDir) {
 // First try the normal rename.
 File target = new File(targetDir, source.getName());

 boolean success = source.renameTo(target);

 if (!success) {
    success = copyFile(context, source, targetDir);
    if (success) {
       success = deleteFile(context, source);
    }
 }
 //if (success) scanFile(context, new String[]{ source.getPath(), target.getPath() });
 return success;

}

This is how we have implemented the functionality to restore a deleted image 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.

Resources

  1. Android Developer documentation –https://developer.android.com/reference/java/io/File
  2. Github-Phimpme Android Repository – https://github.com/fossasia/phimpme-android/
  3. Renaming a file in java – http://stacktips.com/tutorials/java/how-to-delete-and-rename-a-file-in-java
Continue ReadingOption to Restore Deleted Images in Phimpme Android Application

Move Photos from one Path to Another in Phimpme Android Application

In the Phimpme Android application, users can perform various operations on images such as editing an image, sharing an image, printing a pdf version of the image and many more. However, another important functionality that has been implemented is the option to move an image from one path(folder) to another. So in this blog post, I will be discussing how we achieved the functionality to move any image.

Step 1

First, we need to add an option in the overflow menu to move any no of images from one folder to another. The option to move an image has been added by implementing the following lines of code in the  menu_view_pager.xml file.

<item
  android:id=“@+id/action_move”
  app:showAsAction=“never”
  android:title=“Move”/>

Step 2

Now after the user opts for the move operation, a bottomSheetDialog containing all the albums/folders in the storage to choose for moving the photos into will be displayed. Once the user selects the required location to move the photos to, a method moveSelectedMedia would be invoked passing-in the context and the destination path as the parameters. Thereafter inside the method moveSelectedMedia, first a check would be performed to determine whether the selected photos(to move) are already present in the folder(path folder and destination folder both are same), if true the operation would be terminated as the photos are already present in the destination folder, and if false the selected photos would be moved to the destination folder one by one by the use of another method moveMedia. The code snippets used to implement the moveSelectedMedia is provided below.

public int moveSelectedMedia(Context context, String targetDir) {
 int n = 0;
 try
 {
    int index=-1;
    for(int i =0;i<selectedMedias.size();i++)
    {
       String s = selectedMedias.get(i).getPath();
       int indexOfLastSlash = s.lastIndexOf(“/”);
       String fileName = s.substring(indexOfLastSlash + 1);

       if(!selectedMedias.get(i).getPath().equals(targetDir+“/”+fileName)){
          index=-1;
       }else{
          index=i;
          break;

       }
    }
    if(index!=-1)
    {
       n = –1;
    }else{
       for (int i = 0; i < selectedMedias.size(); i++) {

          if (moveMedia(context, selectedMedias.get(i).getPath(), targetDir)) {
             String from = selectedMedias.get(i).getPath();
             scanFile(context, new String[]{ from, StringUtils.getPhotoPathMoved(selectedMedias.get(i).getPath(), targetDir) },
                   new MediaScannerConnection.OnScanCompletedListener() {
                      @Override
                      public void onScanCompleted(String s, Uri uri) {
                         Log.d(“scanFile”, “onScanCompleted: “ + s);
                      }
                   });
             media.remove(selectedMedias.get(i));
             n++;
          }
       }
       setCount(media.size());
    }
 } catch (Exception e) { e.printStackTrace(); }
 return n;
}

Step 3

In this step, I’d discuss the use and implementation of the moveMedia method mentioned in the earlier step. So the moveMedia is used to move a single photo to a particular destination, taking-in the context, the oldpath of the photo and the destination folder as parameters. Inside this method another method moveFile of the ContentHelper class is invoked passing-in the context, File object of the photo and File object of the destination folder as parameters. Now inside the moveFile method the actual move operation takes place. First the photo is tried to move by doing a normal rename operation by using the renameTo function of the File class. The success of the rename operation updates the path of the photo to the destination path and deletes the original path of the photo whereas if the normal rename operation fails, then the photo is moved by first performing a copy operation to copy the photo to the destination folder and then deleting the original photo. The code snippets used to implement the moveMedia and moveFile functions are provided below.

private boolean moveMedia(Context context, String source, String targetDir) {
 File from = new File(source);
 File to = new File(targetDir);
 return ContentHelper.moveFile(context, from, to);
}
public static boolean moveFile(Context context, @NonNull final File source, @NonNull final File targetDir) {
 // First try the normal rename.
 File target = new File(targetDir, source.getName());

 boolean success = source.renameTo(target);

 if (!success) {
    success = copyFile(context, source, targetDir);
    if (success) {
       success = deleteFile(context, source);
    }
 }

 //if (success) scanFile(context, new String[]{ source.getPath(), target.getPath() });
 return success;
}

And at last, after the photos are moved successfully the media adapter is called with the updated photos list to display thus displaying the remaining photos in the folder.

This is how we have implemented the functionality to move images from one path to another 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.

Resources

1. Android Developer documentation –              https://developer.android.com/reference/java/io/File

2. Github-Phimpme Android Repository – https://github.com/fossasia/phimpme- android/

3. Renaming a file in java – http://stacktips.com/tutorials/java/how-to-delete-and-rename-a-file-in-java

Continue ReadingMove Photos from one Path to Another in Phimpme Android Application

Implementing Trash Bin in Phimpme Android Application

In the Phimpme Android application, users can perform various operations/actions on the photos available, some of the important operations involve renaming an image, sharing an image, deleting image etc. However, when the user performs delete operation for image/images the images are permanently deleted from the storage and there is no option to restore/recover the deleted image. Now imagine a situation where the user accidentally or in a rush deletes photo/photos, and now there is no possible way for the user to recover those accidentally deleted photos, so in such circumstances, the Trash Bin feature could prove to be a breather for the user. So, in this blog post, I will be discussing the implementation of the Trash Bin feature.

Step 1

Firstly, we need to implement the functionality to move the images to bin folder whenever the delete operation is performed. For this, we’d programmatically create a folder naming it .nomedia, so that this folder is not picked up by any other similar application while scanning folders. Now when the user deletes images, a check would be performed first to determine whether the bin folder already exists or not and actions would be performed accordingly(a folder would be created if it doesn’t already exist and the selected photos for deletion would be moved to the bin folder or the deleted photos would be moved directly to the bin folder if its there). Code snippets used to implement the bin folder is provided below.

private boolean addToTrash(){
  int no = 0;
  boolean succ = false;
  File file = new File(Environment.getExternalStorageDirectory() + “/” + “.nomedia”);
  if(file.exists() && file.isDirectory()){
      if(!all_photos && !fav_photos && editMode){
          no = getAlbum().moveSelectedMedia(getApplicationContext(), file.getAbsolutePath());
      }else if(all_photos && !fav_photos && editMode){
          no = getAlbum().moveAllMedia(getApplicationContext(), file.getAbsolutePath(), selectedMedias);
      }else if(!editMode && !all_photos && !fav_photos){
          no = getAlbum().moveAllMedia(getApplicationContext(), file.getAbsolutePath(), getAlbum().getMedia());
      }
  else{
      if(file.mkdir()){
          if(!all_photos && !fav_photos && editMode){
              no = getAlbum().moveSelectedMedia(getApplicationContext(), file.getAbsolutePath());
          }else if(all_photos && !fav_photos && editMode){
              no = getAlbum().moveAllMedia(getApplicationContext(), file.getAbsolutePath(), selectedMedias);
          }else if(!editMode && !all_photos && !fav_photos){
              no = getAlbum().moveAllMedia(getApplicationContext(), file.getAbsolutePath(), getAlbum().getMedia());
          }
         // no = getAlbum().moveSelectedMedia(getApplicationContext(), file.getAbsolutePath());
       }
 // clearSelectedPhotos();
  return succ;
}

Step 2

Now if all the photos(selected by the user for deletion) are successfully moved to the bin folder, realm objects corresponding to those image files would be created and added to the realm database. The corresponding Realm object would consist of attributes namely oldpath, trashbinpath, time of delete and duration. The realm objects would be used at the time of implementing restore functionality for the trash bin images. The realm model class representing the Trash bin object is provided below.

public class TrashBinRealmModel extends RealmObject {

  @PrimaryKey
  private String trashbinpath;
  private String oldpath;
  private String datetime;
  private String timeperiod;

  public TrashBinRealmModel(){

  }

  public TrashBinRealmModel(String oldpath, String newpath, String datetime, String timeperiod){
      this.oldpath = oldpath;
      this.trashbinpath = newpath;
      this.datetime = datetime;
      this.timeperiod = timeperiod;
  }

  public void setTrashbinpath(String trashbinpath){
      this.trashbinpath = trashbinpath;
  }

  public String getTrashbinpath(){
      return trashbinpath;
  }
  public void setDatetime(String datetime){
      this.datetime = datetime;
  }

  public String getDatetime(){
      return datetime;
  }

  public void setOldpath(String oldpath){
      this.oldpath = oldpath;
  }

  public String getOldpath(){
      return oldpath;
  }

  public void setTimeperiod(String timeperiod){
      this.timeperiod = timeperiod;
  }

  public String getTimeperiod(){
      return timeperiod;
  }
}

The implementation for the function to add trash bin objects to Realm database is provided below.

for(int i = 0; i < media.size(); i++){
  int index = media.get(i).getPath().lastIndexOf(“/”);
  String name = media.get(i).getPath().substring(index + 1);
  realm.beginTransaction();
  String trashpath = trashbinpath + “/” + name;
  TrashBinRealmModel trashBinRealmModel =   realm.createObject(TrashBinRealmModel.class, trashpath);
  trashBinRealmModel.setOldpath(media.get(i).getPath());
  trashBinRealmModel.setDatetime(new SimpleDateFormat(“dd/MM/yyyy HH:mm:ss”).format(new Date()));
  trashBinRealmModel.setTimeperiod(“null”);
  realm.commitTransaction();
}

Step 3

Now we need to provide an option to the user to navigate to the Trash bin section to perform the delete(permanently) or restore option. So for the aforementioned action, we’d be adding an option in the navigation drawer menu titled “Trash Bin” clicking on which the Trash Bin section would be displayed to the user. The XML code changes committed to implementing the option has been provided below.

<LinearLayout xmlns:android=“http://schemas.android.com/apk/res/android”
            android:id=“@+id/ll_drawer_trashbin”
            android:layout_width=“match_parent”
            android:layout_height=“wrap_content”
            android:background=“@drawable/ripple”
            android:clickable=“true”
            android:orientation=“horizontal”>

  <com.mikepenz.iconics.view.IconicsImageView
      android:id=“@+id/Drawer_trash_Icon”
      android:layout_width=“@dimen/icon_width_height”
      android:layout_height=“@dimen/icon_width_height”
      android:layout_gravity=“center_vertical”
      android:layout_marginLeft=“@dimen/big_spacing”
      android:layout_marginRight=“@dimen/big_spacing”
      app:iiv_icon=“gmd-file-upload”/>

  <TextView
      android:id=“@+id/Drawer_trash_Item”
      android:layout_width=“wrap_content”
      android:layout_height=“wrap_content”
      android:paddingBottom=“16dp”
      android:paddingTop=“16dp”
      android:text=“Trash Bin”
      android:textColor=“@color/md_dark_background”
      android:textSize=“16sp”/>
</LinearLayout>

This is how we have implemented the functionality to rename an image 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.

Resources

1. Android Developer documentation –https://developer.android.com/reference/java/io/File

2. Github-Phimpme Android Repository –https://github.com/fossasia/phimpme-android/

3. Realm for Android tutorial –https://www.androidhive.info/2016/05/android-working-with-realm-database-replacing-sqlite-core-data/

4. Hiding directories using .nomedia file –http://www.easycodeway.com/2016/08/hide-files-in-android-using-nomedia-file.html

Continue ReadingImplementing Trash Bin in Phimpme Android Application

Option to pin albums in Phimpme Android Application

In the Phimpme Android application, users are provided with options to perform various operations on the albums available such as move, creating a zip file of the album, rename an album and many more. However, one another useful functionality that has been added to the Phimpme Android application is the option to pin albums. So in this post, I will be discussing the implementation of the pin to top functionality.

Step 1

First, we need to add an option in the overflow menu to pin the album which has been selected, to the top. The pin to top option can be added in the overflow menu by implementing the following lines of code in the menu_albums.xml file(This file contains the overflow menu options for albums).

<item
  android:id=“@+id/set_pin_album”
  android:title=“@string/pin”
  app:showAsAction=“never” />

Step 2

Now when the user selects the option to pin any album to the top, the user’s choice of the selected album is retrieved by the getSelectedAlbum method of Handling Albums class. Thereafter the togglePin method of class Album Settings is invoked, passing in the context as a parameter. In the togglePin method an instance of the CustomHelper class is obtained first, then its pinAlbum method is called passing in the album path and a variable pinned as the parameters. Here depending on the boolean value of the variable pinned, the selected album will be pinned or unpinned. The code snippets used to implement getSelectedAlbum and togglePin method are provided below.

public Album getSelectedAlbum(int index) {
return selectedAlbums.get(index);
}
public void togglePin(Context context) {
this.pinned = !pinned;
CustomAlbumsHelper h = CustomAlbumsHelper.getInstance(context);
h.pinAlbum(path, pinned);
}

The getSelectedAlbum method and the togglePin method are subsequently used by the following line of code.

getAlbums().getSelectedAlbum(0).settings.togglePin(getApplicationContext());

Step 3

In this step, I’d discuss the implementation of the pinAlbum method invoked inside the togglePin method. In the pinAlbum method, first a writable instance of album_settings SQLite database is obtained. The album_settings database maintains information about the albums in a table with the name of the table Albums and the columns representing info about the album such as path, excluded, pinned, sortorder etc. Next, the checkAndCreateAlbum method would be invoked passing in the writable instance of the database and path of the album as parameters. Now inside the checkAndCreateAlbum method, a check would be performed to determine whether a column representing info about the selected album is already present or not, if not a row is created for the selected album. The code snippet used to implement the checkAndCreateAlbum is provided below.

private void checkAndCreateAlbum(SQLiteDatabase db, String path) {

  Cursor cursor = db.query(TABLE_ALBUMS, null,  ALBUM_PATH+“=?”,
          new String[]{ path }, null, null, null);

  if (cursor.getCount() == 0) {
      ContentValues values = new ContentValues();
      values.put(ALBUM_PATH, path);
      values.put(ALBUM_SORTING_MODE, SortingMode.DATE.getValue());
      values.put(ALBUM_SORTING_ORDER, SortingOrder.DESCENDING.getValue());
      values.put(ALBUM_EXCLUDED, 0);
      db.insert(TABLE_ALBUMS, null, values);
  }

  cursor.close();
}

Now in the pinAlbum method through the writable instance of the album_settings database, the pinned information of the selected album is updated in the Albums table accordingly. The code snippets used to implement the pinAlbum method is provided below.

void pinAlbum(String path, boolean status) {
  SQLiteDatabase db = this.getWritableDatabase();
  checkAndCreateAlbum(db, path);
  ContentValues values = new ContentValues();
  values.put(ALBUM_PINNED, status ? 1 : 0);
  db.update(TABLE_ALBUMS, values, ALBUM_PATH+“=?”, new String[]{ path });
  db.close();
}

At last, the notifyDataSetChanged method of the AlbumsAdapter class would be called so as to display the pinned albums at the top irrespective of the sorting order.

A screenshot displaying the pinned albums at the top in albums view is provided below.

This is how we have implemented the functionality to pin an album to top 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.

Resources

1. Android Developer documentation –https://developer.android.com/reference/android/database/sqlite/SQLiteDatabase

2. Github-Phimpme Android Repository – https://github.com/fossasia/phimpme-android/

3. Sqlite database tutorial for android –https://www.androidhive.info/2011/11/android-sqlite-database-tutorial/.

Continue ReadingOption to pin albums in Phimpme Android Application

Create Call for Speakers with Open Event Organizer Android App

In The Open Event Organizer Android app, we were providing variety of features to the user but the functionality to create call for speakers for an Event was missing. This feature was required to attract speakers from all over the world to participate in the event and make it a success. Theis blog explains how we added this feature to the project us following MVVM Architecture and using libraries like Retrofit, RxJava, Db Flow etc.

Objective

The goal will be to provide an option to the organizer to create Call for Speakers for an Event (if it doesn’t exist already). We will provide the organizer a Floating Action Button in Speakers Call detail layout which will open a fragment which contain all the relevant fields provided by Open Event Server. The organizer can fill up all the fields as per requirement and create the call for speakers.

Specifications

Let’s move on to the implementation details.

First, we will create the model which will contain all the fields offered by server. We are using Lombok library to reduce boilerplate code using annotations. For example, @Data annotation is used to generate getters and setters. @NoArgsConstructor to generate no arguments constructor as the name suggests. Along with that we are using @JonNaming annotation provided by Jackson library to serialize the model using KebabCaseStrategy. Also, the Table annotation provided by Raziz DbFlow library to make a table in database for this model.

@Data
@Type(“speakers-call”)
@NoArgsConstructor
@JsonNaming(PropertyNamingStrategy.KebabCaseStrategy.class)
@Table(database = OrgaDatabase.class, allFields = true)
public class SpeakersCall {@Id(LongIdHandler.class)
@PrimaryKey
public Long id;@Relationship(“event”)
@ForeignKey(onDelete = ForeignKeyAction.CASCADE)
public Event event;

public String announcement;
public String hash;
public String privacy;
public String startsAt;
public String endsAt;
}

To handle this problem we will be using Retrofit 2.3.0 to make Network Requests, which is a REST client for Android and Java by Square Inc. It makes it relatively easy to retrieve and upload JSON (or other structured data) via a REST based Web Service. Also we will be using other awesome libraries like RxJava 2.1.10 (by ReactiveX) to handle tasks asynchronously, Jackson, Jasminb-Json-Api in an MVVM architecture.

We will make a POST request to the server . So we specify the declaration in SpeakersCallApi.java

@POST(“speakers-calls”)
Observable<SpeakersCall> postSpeakersCall(@Body SpeakersCall speakersCall);

We will use the method createSpeakersCall(SpeakersCall speakersCall) in SpeakersCallRepositoryImpl.java to interact with the SpeakersCallApi and make the network request for us. The response will be passed on to the SpeakersCallViewModel method which calls it.

@Override
public Observable<SpeakersCall> createSpeakersCall(SpeakersCall speakersCall) {
if (!repository.isConnected()) {
return Observable.error(new Throwable(Constants.NO_NETWORK));
}return speakersCallApi
.postSpeakersCall(speakersCall)
.doOnNext(created -> {
created.setEvent(speakersCall.getEvent());
repository
.save(SpeakersCall.class, created)
.subscribe();
})
.subscribeOn(Schedulers.io())
.observeOn(AndroidSchedulers.mainThread());
}

Next, we will see the code for SpeakersCallViewModel which is using MVVM ViewModel to handle the processing logic for SpeakesCallFragment. Here we are passing SpeakersCallRepository instance in constructor. Methods like getProgress, getError and getSuccess pass on a LiveData Object from ViewModel to Fragment and the latter observes the changes on the object and show these in UI. CreateSpeakersCall method is used to call speakersCallRepository to send a POST request to server asynchronously using Retrofit and RxJava. Further, initialize method is used to set initial values of time and date to SpeakersCall object.

public class CreateSpeakersCallViewModel extends ViewModel {
public void createSpeakersCall(long eventId) {
if (!verify())
return;Event event = new Event();event.setId(eventId);
speakersCallLive.getValue().setEvent(event);

compositeDisposable.add(speakersCallRepository.createSpeakersCall(speakersCallLive.getValue())
.doOnSubscribe(disposable -> progress.setValue(true))
.doFinally(() -> progress.setValue(false))
.subscribe(var -> success.setValue(“Speakers Call Created Successfully”),
throwable -> error.setValue(ErrorUtils.getMessage(throwable))));
}
}

We will create a Fragment class to bind the UI elements to the Model class so that they can be processed by ViewModel. The creation form contains less fields therefore BaseBottomSheetFragment is used. In the onStart method, we are binding several LiveData objects like SpeakersCall, Progress, Error, Success to the UI and then observe changes in them. Using LiveData we don’t have to write extra code to handle screen rotation and to update UI when the binded object is modified.

public class CreateSpeakersCallFragment extends BaseBottomSheetFragment implements CreateSpeakersCallView {
@Override
public void onStart() {
super.onStart();
createSpeakersCallViewModel.getSpeakersCall().observe(this, this::showSpeakersCall);
createSpeakersCallViewModel.getProgress().observe(this, this::showProgress);
createSpeakersCallViewModel.getError().observe(this, this::showError);
createSpeakersCallViewModel.getSuccess().observe(this, this::onSuccess);
createSpeakersCallViewModel.initialize();
}
}

We will design the speaker create form using Two Way Data Binding to bind SpeakersCall object to the UI and use TextInputEditText to take user Input. Along with that we have used Time and Date pickers to make it easier to select Date and Time. For viewing the complete code, please refer here.

Thus, we are able to build a responsive, reactive UI using Android Architectural Components.

References

  1. Official documentation of Retrofit 2.x http://square.github.io/retrofit/
  2. Official documentation for RxJava 2.x https://github.com/ReactiveX/RxJava
  3. Official documentation for ViewModel https://developer.android.com/topic/libraries/architecture/viewmodel
  4. Codebase for Open Event Orga App https://github.com/fossasia/open-event-orga-app
Continue ReadingCreate Call for Speakers with Open Event Organizer Android App

Building SUSI.AI Android App with FDroid

Fdroid is an app store for Free and Open Source Software (FOSS). Building and hosting an app on Fdroid is not an easy process compared to when we host one on Google Play. A certain set of build checks are required to be done prior to making a merge request (which is similar to a pull request in GitHub) in the fdroid-data GitLab repository. SUSI.AI Android app has undergone through all these checks and tests and is now ready for the merge request to be made.

Setting up the fdroid-server and fdroid-data repositories is a separate thing and is fairly easy. Building the app using the tools provided by fdroid is another thing and is the one that causes the most problems. It will involve quite a few steps to get started. Fdroid requires all the apps need to be built using:

$ fdroid build -v -l ai.susi

This will output a set of logs which tell us what went wrong in the builds. The usual one in a first time app is obviously the build is not taking place at all. The reason is our metadata file needs to be changed to initiate a build.

The metadata file is used for the build process and contains all the information about the app. The metadata file for a.susi package was a .yaml file.

Builds:

 – versionName: 1.0.10

   versionCode: 11

   commit: 1ad2fd0e858b1256617e652c6c8ce1b8372473e6

   subdir: app

   gradle:

     – fdroid

This is the metadata reference file’s build section that is used for the build process using the command that was mentioned above.The versionName a nd versionCode is found in the build.gradle file in the app and commit denotes the commit-id of the latest commit that will be checked out and built, subdir shows the subdirectory of the app, here the subdirectory is the app file.

Next is the interesting stuff, since we are using flavors in the app, we have to mention in the gradle the flavor which we are using, in our case we are using the flavor by the name of “fdroid” and by mentioning this we can build only the “fdroid” flavor in the app.

Also when building the app there were many blockers that were faced, the reason for the usual build fails were :

1 actionable task: 1 executed
INFO: Scanning source for common problems…
ERROR: Found usual suspect ‘youtube.*android.*player.*api’ at app/libs/YouTubeAndroidPlayerApi.jar
WARNING: Found JAR file at app/libs/YouTubeAndroidPlayerApi.jar
WARNING: Found possible binary at app/src/main/assets/snowboy/alexa_02092017.umdl
WARNING: Found possible binary at app/src/main/assets/snowboy/common.res
ERROR: Found shared library at app/src/main/jniLibs/arm64-v8a/libsnowboy-detect-android.so
ERROR: Found shared library at app/src/main/jniLibs/armeabi-v7a/libsnowboy-detect-android.so
INFO: Removing gradle-wrapper.jar at gradle/wrapper/gradle-wrapper.jar
ERROR: Could not build app ai.susi: Can‘t build due to 3 errors while scanning
INFO: Finished
INFO: 1 build failed

The reason for these build fails were that fdroid does not allow us to use prebuilt files and any proprietary software if present, the above log indicates the two prebuilt files which should be removed and also the YouTubeAndroidPlayerApi.jar which is proprietary software and hence needs to removed. So, to remove the files that are not used in the fdroid flavor and exclude them in the build process, we have to include the following statements in the build section of the metadata reference file :

   rm:
     – app/src/main/jniLibs/arm64-v8a/libsnowboy-detect-android.so
     – app/src/main/jniLibs/armeabi-v7a/libsnowboy-detect-android.so
     – app/libs/YouTubeAndroidPlayerApi.jar

Once the metadata file is complete we are ready to run the build command once again. If you have properly set the environment in your local PC, build will end successfully assuming there were no Java or any other language syntax errors.

It is worth to mention few other facts which are common to Android software projects. Usually the source code is packed in a folder named “app” inside the repository and this is the common scenario if Android Studio builds up the project from scratch. If this “app” folder is one level below the root, that is “android/app”, the build instructions shown above will throw an error as it cannot find the project files.

The reason for this is as it is mentioned “subdir=app” in the metadata file. Change this to “subdir=android/app” and run the build again. The idea is to direct the build to find where the project files are.

Reference:

  1. Metadata : https://f-droid.org/docs/Build_Metadata_Reference/#Build
  2. Publish an app on fdroid: https://blog.fossasia.org/publish-an-open-source-app-on-fdroid/
Continue ReadingBuilding SUSI.AI Android App with FDroid

Option to Rename an Image in Phimpme Android Application

In the Phimpme Android application, users can perform various operations on images such as editing an image, sharing an image, moving the image to another folder, printing a pdf version of the image and many more. However, another important functionality that has been implemented is the option to rename an image. So in this blog post, I will be discussing how we achieved the functionality to rename an image.

Step 1

First, we need to add an option in the overflow menu to rename the image being viewed. The option to rename an image has been added by implementing the following lines of code in the  menu_view_pager.xml file.

<item
  android:id=“@+id/rename_photo”
  app:showAsAction=“never”
  android:title=“@string/Rename”/>

Step 2

Now after the user chooses the option to rename any image from the overflow menu, an alert dialog with an edittext would be displayed to the user with the old name and provide the user to add a new name for the photo. The dialog box with edittext has been implemented with the following lines of XML code.

<android.support.v7.widget.CardView
  android:layout_width=“match_parent”
  android:layout_height=“wrap_content”
  app:cardCornerRadius=“2dp”
  android:id=“@+id/description_dialog_card”>
  <ScrollView
      android:layout_width=“match_parent”
      android:layout_height=“match_parent”>
      <LinearLayout
          android:layout_width=“match_parent”
          android:layout_height=“wrap_content”
          android:orientation=“vertical”>
          <TextView
              android:id=“@+id/description_dialog_title”
              android:layout_width=“match_parent”
              android:textColor=“@color/md_dark_primary_text”
              android:layout_height=“wrap_content”
              android:background=“@color/md_dark_appbar”
              android:padding=“24dp”
              android:text=“@string/type_description”
              android:textSize=“18sp”
              android:textStyle=“bold” />
          <LinearLayout
              android:id=“@+id/rl_description_dialog”
              android:layout_width=“match_parent”
              android:layout_height=“wrap_content”
              android:orientation=“horizontal”
              android:padding=“15dp”>
              <EditText
                  android:id=“@+id/description_edittxt”
                  android:layout_width=“fill_parent”
                  android:layout_height=“wrap_content”
                  android:padding=“15dp”
                  android:hint=“@string/description_hint”
                  android:textColorHint=“@color/grey”
                  android:layout_margin=“20dp”
                  android:gravity=“top|left”
                  android:inputType=“textCapSentences|textMultiLine”
                  android:maxLength=“2000”
                  android:maxLines=“4”
                  android:selectAllOnFocus=“true”/>
              <ImageButton
                  android:layout_width=“@dimen/mic_image”
                  android:layout_height=“@dimen/mic_image”
                  android:layout_alignRight=“@+id/description_edittxt”
                  app2:srcCompat=“@drawable/ic_mic_black”
                  android:layout_gravity=“center”
                  android:background=“@color/transparent”
                  android:paddingEnd=“10dp”
                  android:paddingTop=“12dp”
                  android:id=“@+id/voice_input”/>
          </LinearLayout>
      </LinearLayout>
  </ScrollView>
</android.support.v7.widget.CardView>

The screenshot displaying the dialog with edittext is provided below.

Step 3

Now after retrieving the new name entered by the user for the photo we would extract the extension of the old name which can be .jpg, .png etc. Thereafter we’d need to create a new File object passing in the new path of the image(the path folder remains the same only the image name gets changed to a new one) as the constructor parameter. Now using the renameTo method of the File class the old image file can be renamed. However, with this rename operation the image reference would not be automatically updated in the MediaStore database. So we’d need to delete the old file path from the Android system MediaStore database which keeps a URI reference to all the media files present on the device. At last, we’d need to invoke the MediaScanner class to scan all the media files so that the new file path of the renamed image is scanned and is picked up by the MediaStore database. This can be done with the help of an action intent to initiate the media scan action. The code changes implemented to perform the above-mentioned operation is given below.

public void onClick(View dialog) {
      if (editTextNewName.length() != 0) {
          int index = file.getPath().lastIndexOf(“/”);
          String path = file.getPath().substring(0, index);
          File newname = new File(path + “/” + editTextNewName.getText().toString() + “.” +
                  imageextension);
          if(file.renameTo(newname)){
              ContentResolver resolver = getApplicationContext().getContentResolver();
              resolver.delete(
                      MediaStore.Images.Media.EXTERNAL_CONTENT_URI, MediaStore.Images.Media.DATA +
                              “=?”, new String[] { file.getAbsolutePath() });
              Intent intent = new Intent(Intent.ACTION_MEDIA_SCANNER_SCAN_FILE);
              intent.setData(Uri.fromFile(newname));
              getApplicationContext().sendBroadcast(intent);
          }
          if(!allPhotoMode){
              int a = getAlbum().getCurrentMediaIndex();
              getAlbum().getMedia(a).setPath(newname.getPath());
          }else {
              listAll.get(current_image_pos).setPath(newname.getPath());
          }
          renameDialog.dismiss();
          SnackBarHandler.showWithBottomMargin(parentView, getString(R.string.rename_succes), navigationView
                  .getHeight());
      } else {
          SnackBarHandler.showWithBottomMargin(parentView, getString(R.string.insert_something),
                  navigationView.getHeight());
          editTextNewName.requestFocus();
      }
  }
});

This is how we have implemented the functionality to rename an image 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.

Resources

1.Android Developer documentation-https://developer.android.com/reference/java/io/File

2.Github-Phimpme Android Repository – https://github.com/fossasia/phimpme-android/

3.Renaming a file in java – http://stacktips.com/tutorials/java/how-to-delete-and-rename-a-file-in-java

 

Continue ReadingOption to Rename an Image in Phimpme Android Application

Option to delete albums from storage in Phimpme Android Application

In the Phimpme Android application, users can perform various operations on the albums available such as creating a zip file of the album, hiding an album and many more. However, one another useful functionality that has been added to the Phimpme Android application is the option to delete unwanted albums permanently from the storage. So in this post, I will be discussing how we implemented the functionality to delete albums.

Step 1

First, we need to provide an option in the overflow menu to delete album/albums when the user long-selects album/albums or the user is viewing photos inside a particular album. The option in the overflow menu can be added by integrating following lines of code in the menu_albums.xml file(this file contains the XML code for overflow menu options provided for albums).

 <item
android:id=”@+id/delete_action”
android:title=”@string/delete”
app:showAsAction=”ifRoom” />

Step 2

Now when the user opts to delete some selected albums, we need to retrieve user’s choice of albums to delete and store it in an ArrayList<Album> to keep track of the albums and for further use. We would here also keep track of all the albums displayed currently to the user through another ArrayList<Album> named displayAlbums. Thereafter deleteSelectedAlbums method of class HandlingAlbums will be invoked passing in the activity context as the parameter. Now in this method we’d iterate through the ArrayList<Album>(ArrayList used to store user’s choice of albums to delete) and in turn invoke another method deleteAlbum with each iteration, passing in the album and context as the parameters. The deleteAlbum method would return a boolean value that will indicate whether or not the particular album was successfully deleted. If the boolean value returned is true, indicating that the particular album and its contents have been permanently deleted from the device storage, then we would delete that particular album object from the displayAlbums list and the AlbumsAdapter would be notified to display the remaining set of albums by passing in the modified displayAlbums list. The code snippet used to implement the method deleteSelectedAlbums and deleteAlbum is provided below.

public boolean deleteSelectedAlbums(Context context) {
boolean success = true;

for (Album selectedAlbum : selectedAlbums) {
  int index = dispAlbums.indexOf(selectedAlbum);
  if(deleteAlbum(selectedAlbum, context))
    dispAlbums.remove(index);
  else success = false;
}
return success;
}
public boolean deleteAlbum(Album album, Context context) {
return ContentHelper.deleteFilesInFolder(context, new File(album.getPath()));
}

Step 3

In the previous step, we were invoking a function deleteAlbum which would return a boolean variable denoting whether the album was deleted permanently or not. Therefore in this step, I’d be discussing the working of the deleteAlbum method. So the deleteAlbum method was being invoked passing in the album to delete and the context as the parameters. This method, in turn invokes the deleteFilesInFolder method of the ContentHelper class passing in the context and a File object created from the album path(to be deleted). This method returns a boolean variable indicating the success or failure of the operation and this variable is in turn returned by the deleteAlbum method. The code representing the function invoke has been provided above. The code snippet representing the deleteFilesInFolder method is provided below.

public static boolean deleteFilesInFolder(Context context, @NonNull final File folder) {
 boolean totalSuccess = true;

 String[] children = folder.list();
 if (children != null) {
    for (String child : children) {
       File file = new File(folder, child);
       if (!file.isDirectory()) {
          boolean success = deleteFile(context, file);
          if (!success) {
             Log.w(TAG, “Failed to delete file” + child);
             totalSuccess = false;
          }
       }
    }
 }
 return totalSuccess;
}

Now inside the deleteFilesInFolder method first all the contents of the file are stored in a String[] array child. Thereafter by iterating through the child array, every time a method deleteFile is invoked passing in an item from the child array(an image path) and the context as parameters, which returns a boolean variable indicating if the particular image content is deleted or not.

Now depending on which Android version the device is running, there are two methods used to delete the image file permanently from the storage.

If the device is running on version LOLLIPOP and above, the Android Storage Access Framework has been used to delete the image file, and if the device is running version KITKAT, the MediaStore content provider is used to delete the file from device’s storage. The code snippet implementing the deleteFile method is provided below.

public static boolean deleteFile(Context context, @NonNull final File file) {
 boolean success = file.delete();

 // Try with Storage Access Framework.
 if (!success && Build.VERSION.SDK_INT >= Build.VERSION_CODES.LOLLIPOP) {
    DocumentFile document = getDocumentFile(context, file, false, false);
    success = document != null && document.delete();
 }

 // Try the Kitkat workaround.
 if (!success && Build.VERSION.SDK_INT == Build.VERSION_CODES.KITKAT) {
    ContentResolver resolver = context.getContentResolver();

    try {
       Uri uri = null;//MediaStoreUtil.getUriFromFile(file.getAbsolutePath());
       if (uri != null) {
          resolver.delete(uri, null, null);
       }
       success = !file.exists();
    }
    catch (Exception e) {
       Log.e(TAG, “Error when deleting file “ + file.getAbsolutePath(), e);
       return false;
    }
 }

 if(success) scanFile(context, new String[]{ file.getPath() });
 return success;
}

This is how we achieved the functionality to delete album/albums from the storage 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.

Resources

1.Android Developer Guide – https://developer.android.com/guide/topics/providers/document-provider#delete

2.Github-Phimpme Android Repository – https://github.com/fossasia/phimpme-android/

3.MediaStore class – https://developer.android.com/reference/android/provider/MediaStore

4.Deleting files via Android media content provider – https://stackoverflow.com/questions/10925196/deleting-files-via-a-contentresolver-as-opposed-to-deleting-them-via-file-del

Continue ReadingOption to delete albums from storage in Phimpme Android Application