evilthreads669966 / bootlaces Goto Github PK

I'm thinking about picking up a Marijuana habit and starting planet side 2 again. Maby after I'll update the release with the new code.

• I couldn't get room-coroutines to compile so I went without it and accidentally left suspend keyword in there.
  • this could have adverse effects but it worked fine the 3 or 4 times I ran the demo

I was playing with my phone off to the side and I Restarted and my persistent hourly worker didn't run after reboot so I kicked the system clock up and kept trying and kind of forgot but now I am really going to check all these while I do something else

• Rename BootReceiver's rescheduleWork function
  • I'm thinking startServiceForRescheduling or just startService

the question is the singleton of the database synchronized. I'm working through some Room documentation right now and it stuck out

• move WorkService's execute function into a new class named WorkExecutor.kt
  • singleton
  • inject into WorkService

• add scheduling functions for calendar time.
  • example tuesdayNoonWorker.scheduleAtNoon(periodic = true, day = tuesday)

• persistent periodic workers are interfering when I schedule a non-periodic persistet worker

I just realized that my adapter is supposed to be named converter....haha, Oh well I can't upload for a year sooo and I am not even supposed to be on here either. This is really my last post and the account is frozen. I shall return on New Years Eve

Thinking surviveReboot parameter will make more sense than persistent.

Okay so I was gonna disable the app icon before I dissapeared but here is what my research brought. I've only been at this for 10 minutes. I spent the last 2 days straight working with jetpack.
Soo if we disable the launcher activity which disables the icon in the launcher... then we can't start that activity to lock the screen...
meaning we must have a second activity for locking the screen that way we can disable the launcher activity and still be able to lock the screen I am working on this right before I go back to working on my core skill set and updating my knowledge of android libraries for the next 6-8 months.

It's complaining about ReschedulingReceiver matching the same key.

C:\Users\evilt\AndroidStudioProjects\EvilScreenNew\app\build\generated\source\kapt\debug\com\evilthreads\App_HiltComponents.java:141: error: [Dagger/MissingBinding] @dagger.hilt.android.qualifiers.ActivityContext android.content.Context cannot be provided without an @Provides-annotated method.
  public abstract static class SingletonC implements ReschedulingReceiver_GeneratedInjector,
                         ^
  A binding with matching key exists in component: com.evilthreads.App_HiltComponents.ActivityC
      @dagger.hilt.android.qualifiers.ActivityContext android.content.Context is injected at
          com.evilthreads.LockObserver(activityContext, �)
      com.evilthreads.LockObserver is injected at
          com.evilthreads.lock.ui.LockActivity.lockObserver
      com.evilthreads.lock.ui.LockActivity is injected at
          com.evilthreads.lock.ui.LockActivity_GeneratedInjector.injectLockActivity(com.evilthreads.lock.ui.LockActivity) [com.evilthreads.App_HiltComponents.SingletonC ? com.evilthreads.App_HiltComponents.ActivityRetainedC ? com.evilthreads.App_HiltComponents.ActivityC]

There isn't a bug but I just finished everything and I realized I can get rid of persistent workers. The extra properties aren't needed. It might take some time but it will make it more flexible and it will be cleaner.

Background notification content is not persisting across reboot. This might be related to direct boot but I am not sure.

• multiple persistent workers are not working
  • only the first one scheduled makes it to doWork inside of assignWork in WorkService
  • I have tested with two
    • it makes it into the database and the flow is triggering when collecting from the query on the table
      • assignWorker never gets called on it though

I'm laying in bed like just finishing writing that function and I check my git log and it goes back like 30 merges haha. Wow. I've never felt like this bad before. Like right as my body begins to feel weary and my eyes are burning from the excessive screen exposure and lack off sleep...i guess it feels better though because the end result. makes my eyes lay easier

• need to check whether there is persistent work scheduled before starting the service in BootReceiver
  • after adding periodic work feature it gives the BootReceiver more responsibility
    • The BootReceiver component may be enabled without the need for the work service to be started.
    • Whenever an alarm is triggered it will broadcast to the same receiver and it will make a work request which starts the service when needed
  • This will prevent the service from being started everytime the phone reboots in the event that we have periodic work and not persistent work
• this is more of a optimization than a bug

Since WorkRescheduling is only use one time only, it should perhaps be only instantiated once and then let it be garbage collected

changing work from public to internal broke the build

• not a bug but I marked the functions internal before the classes
  • I was under the impression that if you use @Inject on a class public constructor that it had to be made public
  • I have no idea why I was under the impression that classes with injectable constructors in Hilt had to be public
    • made me wonder what the benefit of Hilt is in a library

Display background work notification on watches.

• add scheduling functions for clock time.
  • example noonWorker.scheduleNoon(periodic = true)
    • would execute work at noon everyday
  • example 2amWorker.scheduleAtTwo(meridiem = AM)

2020-12-31 20:35:20.074 4776-4853/com.candroid.lacedboots D/Hourly worker: working hourly
2020-12-31 20:35:20.085 4776-4850/com.candroid.lacedboots D/Hourly worker: working hourly
2020-12-31 20:35:20.125 4776-4845/com.candroid.lacedboots D/Hourly worker: working hourly

• need a way to know whether a periodic worker has already been scheduled

in the app implementation would look like this

• however the problem is that you have to be inside the ktx of WorkScheduler to have access

fun WorkScheduler.scheduleWork() {
    PersistentWorker().schedulePersistent()
    FirstFutureWorker().scheduleFuture(10000L, true, true)
}

I'd love to see it look like this for the user of Boot Laces taking away the need for the scheduler

   onCreate(...){
      PersistentWorker().schedulePersistent()
      FirstFutureWorker().scheduleFuture(10000L, true, true)
   }

prototype of public and internal API but I would have to get scheduler into it's own component so it could just be a container fo alarm manager and intent factory and it would be internal instead of public how it is now...really I mean WorkScheduler is it's own component already but I need to decouple it from actually scheduling and rename it to something else

class WorkScheduler @Inject constructor(@ApplicationContext val ctx: Context, val alarmMgr: AlarmManager, val factory: IntentFactory) {
    fun Worker.schedulePersistent() = schedule(ctx, factory)

    fun Worker.scheduleNow(): Boolean = schedule(factory, alarmMgr, 0L, false, false)

    fun Worker.scheduleFuture(delay: Long, repeating: Boolean = false, wakeupIfIdle: Boolean = false): Boolean =
        schedule(factory, alarmMgr, delay, repeating, wakeupIfIdle)

    fun Worker.scheduleHour(repeating: Boolean = false, wakeupIfIdle: Boolean = false): Boolean =
        schedule(factory, alarmMgr, AlarmManager.INTERVAL_HOUR, repeating, wakeupIfIdle)

    fun Worker.scheduleQuarterDay(repeating: Boolean = false, wakeupIfIdle: Boolean = false): Boolean =
        schedule(factory, alarmMgr, AlarmManager.INTERVAL_HOUR * 6, repeating, wakeupIfIdle)
}


internal fun Worker.schedule(factory: IntentFactory, alarmMgr: AlarmManager, interval: Long, repeating: Boolean, wakeupIfIdle: Boolean): Boolean{
    val pendingIntent = factory.createPendingIntent(this.toWork()) ?: return false
    var alarmTimeType: Int = AlarmManager.RTC
    val triggerTime = System.currentTimeMillis() + interval
    if(wakeupIfIdle)
        alarmTimeType = AlarmManager.RTC_WAKEUP
    if(repeating)
        alarmMgr.setRepeating(alarmTimeType, triggerTime, interval, pendingIntent)
    else
        if(wakeupIfIdle)
            alarmMgr.setExactAndAllowWhileIdle(alarmTimeType, triggerTime, pendingIntent)
        else
            alarmMgr.setExact(alarmTimeType, triggerTime, pendingIntent)
    return true
}

///TWO Internal KTX functions for internal API one schedules non-persistent and the other persistent
internal fun Worker.schedule(ctx: Context, factory: IntentFactory){
    val intent = factory.createWorkIntent(this.toWork(), Actions.ACTION_WORK_PERSISTENT)
    if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.O)
        ctx.startForegroundService(intent)
    else
        ctx.startService(intent)
    WorkService.persist(ctx)
}

• I don't know how long this has been going on but I think it was regressional
  • They don't happen after reboot

• Just finished up shedule before and after reboot
  • this causes the internals for managing when and how to show the foreground notification to have changed
    • it's not broken but must be fixed

• rename WorkSchedulerFacade.kt to WorkRescheduler and its' function to reschedule
  • workRescheduler.reschedule