Refactoring DeviceProfile
-> Pulling out the parts of device profile which can (and need to be)
initialized and accessed without access to an Activity context,
ie. the invariant bits.
-> The invariant bits are stored in InvariantDeviceProfile which is
initialized statically from LauncherAppState.
-> The DeviceProfile contains the Activity context-dependent bits,
and we will create one of these for each Activity instance, and
this instance is accessed through the Launcher activity.
-> It's possible that we can continue to refactor this such that
all appropriate dimensions can be computed without an Activity
context (by only specifying orientation). This would be an
extension of this CL and allow us to know exactly how launcher
will look in both orientations from any context.
Sets the stage for some improvements around b/19514688
Change-Id: Ia7daccf14d8ca2b9cb340b8780b684769e9f1892
diff --git a/src/com/android/launcher3/LauncherAppWidgetHostView.java b/src/com/android/launcher3/LauncherAppWidgetHostView.java
index 954d2d7..71fb2d2 100644
--- a/src/com/android/launcher3/LauncherAppWidgetHostView.java
+++ b/src/com/android/launcher3/LauncherAppWidgetHostView.java
@@ -152,6 +152,10 @@
return info;
}
+ public LauncherAppWidgetProviderInfo getLauncherAppWidgetProviderInfo() {
+ return (LauncherAppWidgetProviderInfo) getAppWidgetInfo();
+ }
+
@Override
public void onTouchComplete() {
if (!mLongPressHelper.hasPerformedLongPress()) {