静态方法与类扩展android.app.Application?

时间:2011-12-28 15:50:09

标签: android methods static parameter-passing

我有一个在Android tabHost应用程序中扩展Application的类。在App类中,我一直在放置方法和变量,否则我需要在每个类中重新创建。一种方法从DB读取并将结果存储在ArrayList(例如,名字,姓氏)中。我没有重新读取这个数据库并为每个需要信息的选项卡视图重新创建代码,而是将方法和ArrayList放在扩展Application(myAppClass)的类中。这样,通过在onCreate()的任何选项卡视图中设置mAC = (myAppClass) getApplicationContext(),我可以引用myAppClass中的所有get ..()和set ..()方法。

我最初的计划是使用带有静态方法和变量的共享类,但我读了很多“不要那样做”的线程,因此决定使用Application路由。现在,我遇到了一种情况,我正在尝试在项目库中使用myAppClass,但是获得有关android.app.Application cannot be cast to...的错误如果我将myAppClass更改回静态方法/变量(并且不扩展Application),事情就会起作用,但这应该是一个很大的禁忌。还有另一种方法吗?不确定Android是否通过引用传递了所有内容,但是我最好通过在方法/类之间来回传递巨大的(数千个对象/成员)ArrayLists来重新实现整个应用程序吗?

1 个答案:

答案 0 :(得分:6)

  

我最初的计划是使用带有静态方法和变量的共享类,但我读了很多“不要那样做”的线程,所以决定使用Application路由。

“不要那样做”通常是针对全球范围内任何内容的建议,因此将涵盖静态数据成员以及自定义Application。两者都可能是内存泄漏的原因。

  

现在,我遇到了一种情况,我正在尝试在项目库中使用myAppClass,但是获取有关android.app.Application的错误无​​法转换为...

托管项目中的清单可能并未声明使用库的Application实现。

  

这应该是一个很大的禁忌

同样,静态数据成员并不比自定义Application更差,并且在许多情况下更好。

  

还有其他办法吗?

不要使用Application或静态数据成员。

  

通过在方法/类之间来回传递巨大的(数千个对象/成员)ArrayLists,我会更好地重新实现整个应用程序吗?

拥有持久数据模型(例如数据库)会更好。使用静态数据成员作为持久数据模型的缓存是可以的,只要您对内存管理非常小心。