Android (JAVA) – Call REST API at specific time at 9:00 am everyday

I am using Alarm Manager to Call REST API. But the Problem is when user change System clock time it get triggered immediately. To call REST API Exectly at 9:00 am mandatory. Suppose User change clock on 8:00 am and alarm get Triggered at 10:00 am so it will cause problem. I am using PHP-MySQL as a Back-end.

You can also say that my alarm will not have to depend on Android System Time. It must be depend on Indian Standard Time.

REST API should be called on exect 9:00 AM

Back-end PHP
REST API called on 9:00 AM exectly.
Alarm Manager get triggered Immediately when user change System Clock Time.

Set Alarm method

   public static void setAlarm(Context context) {

    Intent intent = new Intent(context, MyBroadcastReceiver.class);
    PendingIntent pendingIntent = PendingIntent.getBroadcast(context, 234324243, intent, 0);
    AlarmManager alarmManager = (AlarmManager) context.getSystemService(ALARM_SERVICE);

    Calendar calendar = Calendar.getInstance();
    calendar.setTimeInMillis(System.currentTimeMillis());
    calendar.set(Calendar.HOUR_OF_DAY, 9);
    calendar.set(Calendar.MINUTE, 0);
    calendar.set(Calendar.SECOND, 0);

    if (calendar.before(Calendar.getInstance())) {
        calendar.add(Calendar.DATE, 1);
    }
    alarmManager.set(AlarmManager.RTC_WAKEUP, calendar.getTimeInMillis(), pendingIntent);

  }

BroadcastReceiver.java

      public class MyBroadcastReceiver extends BroadcastReceiver {
      @Override
      public void onReceive(Context context, Intent intent) {

        if (isNetworkConnected(context)) {

           doUpdate(context);
        }
      }

    private void doUpdate(final Context context) {

    class DoInsert extends AsyncTask<String, String, String> {


        @Override
        protected String doInBackground(String... strings) {

            Retrofit retrofit = AppConfig.getRetrofit();
            Api service = retrofit.create(Api.class);

            Call<Response> call = service.doOperation();
            call.enqueue(new Callback<Response>() {
                @Override
                public void onResponse(Call<Response> call, retrofit2.Response<Response> response) {

                    Response response1 = response.body();
                    Log.d("RESPONSE ======== ", response1.getMessage());


                    return;
                }

                @Override
                public void onFailure(Call<Response> call, Throwable t) {

                    Log.d("RESPONSE ======== ", t.getMessage());
                }
            });


            return null;
        }

        @Override
        protected void onPostExecute(String s) {
            super.onPostExecute(s);

            Log.d("RESPONSE ======== ", "Success");

        }
    }
    new DoInsert().execute();
  }


  private boolean isNetworkConnected(Context context) {
       ConnectivityManager cm = (ConnectivityManager) 
       context.getSystemService(Context.CONNECTIVITY_SERVICE);

      return cm.getActiveNetworkInfo() != null && cm.getActiveNetworkInfo().isConnected();
    }

   }

Manifest.xml

 <receiver android:name=".BroadcastReceiver.MyBroadcastReceiver">

        <intent-filter>
            <action android:name="android.intent.ACTION_TIMEZONE_CHANGED" />
        </intent-filter>
        <intent-filter>
            <action android:name="android.intent.ACTION_TIME" />
        </intent-filter>
        <intent-filter>
            <action android:name="android.intent.action.DATE_CHANGED" />
        </intent-filter>
        <intent-filter>
            <action android:name="android.intent.action.TIME_SET" />
        </intent-filter>
        <intent-filter>
            <action android:name="android.intent.action.ACTION_TIME_CHANGED" />
        </intent-filter>

    </receiver>

Answer

After a lot of temporary tricks I have found the solution of it.

Alarm manager will take system time and to avoid it we can use UTC time but I don’t know how to use it.

So, I solved this problem by using Cron Job in php. Web hosting provides Cron Jobs and It actually fits in this scenario because giving privilege to users to modify REST API is quite risky.

At the end Thanks to all who gave their time to my question.

Advertisement

Answer