Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Huawei update not working perfectly #27

Open
NoHarmDan opened this issue Jan 6, 2020 · 1 comment
Open

Huawei update not working perfectly #27

NoHarmDan opened this issue Jan 6, 2020 · 1 comment
Labels
enhancement New feature or request

Comments

@NoHarmDan
Copy link

I'm really glad I could help and happy that you incorporated my suggestions!

There is however one small issue with it - the line with the comment should either return true or not be there at all, which would make it fall down to the return true at the very end of the function body. At the current state, it positively opens the required "fallback" screen, but returns false, causing any dependent application behavior to misbehave (in my case it shows a message that this option is not available).

  private fun autoStartHuawei(context: Context): Boolean {
        if (isPackageExists(context, PACKAGE_HUAWEI_MAIN)) {
            try {
                startIntent(context, PACKAGE_HUAWEI_MAIN, PACKAGE_HUAWEI_COMPONENT)
            } catch (e: Exception) {
                e.printStackTrace()
                try {
                    startIntent(context, PACKAGE_HUAWEI_MAIN, PACKAGE_HUAWEI_COMPONENT_FALLBACK)
                } catch (ex: Exception) {
                    ex.printStackTrace()
                    return false
                }
                return false // this should be true or not here at all
            }
        } else {
            return false
        }

        return true
    }

Btw, a little suggestion, which is more about clean coding - I would refrain from catching an exception while trying to open an activity and falling back to a different one then. The "cleaner" alternative would be to check which one of the activities is actually present beforehand, without having to trigger an exception. But this really shouldn't affect the UX, so it doesn't really matter that much. Though the current fallback will very soon become the primary activity, as Huawei devices get updated.

And one final thought, it would be great to be able to implement a way to get any exceptions (not necessarily catch them outside the library, just to get the instance somehow) that occur while opening an activity in order to be able to report those through say Crashlytics. I have thousands of users which could provide some valuable compatibility data that way. But that's a little off-topic.

@judemanutd judemanutd added enhancement New feature or request bug Something isn't working labels Jan 7, 2020
@judemanutd
Copy link
Owner

@NoHarmDan thanks for catching that bug, I'm on it.

  1. With regards to the exceptions, could you give me an example of what you're looking for?

    • For example with Huawei, it currently has 3 combinations that need to be tried before losing all hope. The only exception at this point I can think of throwing is that no activity found, is there something that you had in mind?
  2. Checking for activities before does look cleaner, it's quite a significant change so I'm going to put a pin on it for now and add it to a roadmap (thanks for the suggestion)

judemanutd pushed a commit that referenced this issue Jan 12, 2020
added fallback activity for asus

closes issue #28
references issue #27
@judemanutd judemanutd removed the bug Something isn't working label Mar 5, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

2 participants