既然我可以通过注册activity生命周期回调的方法在任意地方获取到最后一个onresume的activity，那么我是否可以创建一个工具类，工具类利用这个activity来构造dialog呢？这样做有什么坏处呢？我现在用一个toast工具类，在工具类中直接使用了application的context，这样做可以吗？
闭关修行中......
可以是可以，但为什么要这么做？封装个dialog工具类传activity就行了。至于toast，用applicationContext是一个不错的做法。
构造Dialog直接把Activity的context传过去就可以了呀，不需要你整回调啥的这么麻烦的。你可以参考下别人封装的工具库，看看别人的思路。
抖个机灵，你可以把一个activity当做dialog，只需要把他的主题设置为dialog，官网说的
原本系统级别的dialog是很方便的只需要传入applicationContext就可以实现一个弹框，但是由于各个厂商的过度定制(我遇到小米对系统级别的弹框定制令人恶心，同一个版本，更新一次实现就修改一次)，所以最好还是如上面所有的可以用一个定制dialog格式的activity作为弹出框来实现，目前很多家都是这样的，像tencent的信鸽推送也就是这样做的，能保证成功开启而不受定制之苦。
安卓的Dialog，不管怎么样你都要传Context。传 Activity 其实也就相当于传了 Context。利用Application的Context是不行的；再者，static的Context是不推荐的，有可能会造成内存泄漏。
不过你可以通过依赖注入等方法隐藏或者简化这一过程。
不能(虽然我想表示不建议)建设你已经实现了,我们猜一下这样会发生什么.
网络请求发出去了,然后页面被结束,但是请求没有取消.请求返回时弹了一个对话框.这个Dialog怎么解释?如果这Dialog后续有操作,操作有数据,这些处理的代码放在哪里?也行你成功把这些数据放在Dialog实例里,还new了一个内部类.那么恭喜,刚刚被结束的Activity内存泄漏了
一个万能的Dialog,怎么限制人去使用?可以在任何地方弹,代码结构还能维护?
小项目,直接根据需求抽个BaseActivity,处理好代码结构弹个对话框也没多麻烦.理由不充分.
可以是可以，但为什么要这么做？封装个dialog工具类传activity就行了。至于toast，用applicationContext是一个不错的做法。
构造Dialog直接把Activity的context传过去就可以了呀，不需要你整回调啥的这么麻烦的。你可以参考下别人封装的工具库，看看别人的思路。
抖个机灵，你可以把一个activity当做dialog，只需要把他的主题设置为dialog，官网说的
原本系统级别的dialog是很方便的只需要传入applicationContext就可以实现一个弹框，但是由于各个厂商的过度定制(我遇到小米对系统级别的弹框定制令人恶心，同一个版本，更新一次实现就修改一次)，所以最好还是如上面所有的可以用一个定制dialog格式的activity作为弹出框来实现，目前很多家都是这样的，像tencent的信鸽推送也就是这样做的，能保证成功开启而不受定制之苦。
安卓的Dialog，不管怎么样你都要传Context。传 Activity 其实也就相当于传了 Context。利用Application的Context是不行的；再者，static的Context是不推荐的，有可能会造成内存泄漏。
不过你可以通过依赖注入等方法隐藏或者简化这一过程。
不能(虽然我想表示不建议)
建设你已经实现了,我们猜一下这样会发生什么.
网络请求发出去了,然后页面被结束,但是请求没有取消.请求返回时弹了一个对话框.这个Dialog怎么解释?如果这Dialog后续有操作,操作有数据,这些处理的代码放在哪里?也行你成功把这些数据放在Dialog实例里,还new了一个内部类.那么恭喜,刚刚被结束的Activity内存泄漏了
一个万能的Dialog,怎么限制人去使用?可以在任何地方弹,代码结构还能维护?
小项目,直接根据需求抽个BaseActivity,处理好代码结构弹个对话框也没多麻烦.理由不充分.