ну такого-же эффекта можно и стандартными средствами добиться. Вон lwjgl вообще нативные dll грузит для каждой платформы. Понятно, что это JNI, но, например тот же сменный рендер можно чисто на интерфейсах сделать. Да чо там далеко ходить, взять тот же JECP.

DominaN, DI это про:

вместо


Всего-лишь. Но что-то людям так лень вручную это делать, что они на аннотации всё положили. Сейчас вроде норм, а вот в первых версиях даггера, зависимости динамически на андроиде подключались, а не на этапе компиляции. Сейчас там кодогенерация.

Цитата DominaN:

---

тот же сменный рендер можно чисто на интерфейсахТак это оно и есть. Вот только когда у тебя таких модулей несколько штук и большая иерархия компонентов, то инжектить зависимости через конструкторы утомительно и некрасиво (а через сеттеры ещё и не совсем безопасно). Поэтому и существуют всякие DI-фреймворки типа Dagger, Guice и прочие PicoContainer'ы.

Если вы поместите внутрь CoordinatorLayout другой CoordinatorLayout, то внутренний перехватит все Behaviour's и внешний не будет работать. Этот класс не исправляет этот недостаток. Просто замените вложенный CoordinatorLayout на этот и все заработает. Источник

Открыть спойлер

Закрыть спойлер

[копировать] [скачать]

1. package android.support.design.widget;
2.  
3. import android.content.Context;
4. import android.support.annotation.NonNull;
5. import android.support.annotation.Nullable;
6. import android.support.v4.view.NestedScrollingChildHelper;
7. import android.util.AttributeSet;
8. import android.view.View;
9.  
10. /**
11.  * A CoordinatorLayout, except with changes to make it use less CPU time in some cases.
12.  * To improve performance, use this class instead of CoordinatorLayout.
13.  *
14.  * <p>This class also has the ability to act as both as a Nested scrolling parent and child to consume
15.  * and dispatch scroll callbacks to its parents. This allows it to be used in situations where multiple
16.  * CoordinatorLayouts may be nested.</p>
17.  */
18. public class NestedCoordinatorLayout extends CoordinatorLayout {
19.  
20.     private final NestedScrollingChildHelper nestedScrollingChildHelper;
21.  
22.     public NestedCoordinatorLayout(@NonNull Context context) {
23.         this(context, null);
24.     }
25.  
26.     public NestedCoordinatorLayout(@NonNull Context context, @Nullable AttributeSet attrs) {
27.         this(context, attrs, 0);
28.     }
29.  
30.     public NestedCoordinatorLayout(@NonNull Context context, @Nullable AttributeSet attrs, int defStyleAttr) {
31.         super(context, attrs, defStyleAttr);
32.         nestedScrollingChildHelper = new NestedScrollingChildHelper(this);
33.         nestedScrollingChildHelper.setNestedScrollingEnabled(true);
34.     }
35.  
36.     /**
37.      * The same as super.offsetChildToAnchor, except use less CPU time if the child is "gone".
38.      * In this case, super.offsetChildToAnchor may cause several views to be redrawn.
39.      * This can happen every display frame, so the app hogs CPU time, repeatedly redrawing the same views.
40.      * This was reported as https://code.google.com/p/android/issues/detail?id=196879
41.      */
42.     @Override
43.     void offsetChildToAnchor(@NonNull View child, int layoutDirection) {
44.         // Don't waste CPU time:
45.         if (child.getVisibility() != View.GONE) {
46.             super.offsetChildToAnchor(child, layoutDirection);
47.         }
48.     }
49.  
50.     /**
51.      * Default set to true
52.      */
53.     public void setShouldConsumeAndForwardScrollEvents(boolean shouldConsumeAndForwardScrollEvents) {
54.         nestedScrollingChildHelper.setNestedScrollingEnabled(shouldConsumeAndForwardScrollEvents);
55.     }
56.  
57.     @Override
58.     public boolean onStartNestedScroll(View child, View target, int nestedScrollAxes) {
59.  
60.         boolean shouldAcceptNestedScroll = super.onStartNestedScroll(child, target, nestedScrollAxes);
61.  
62.         if (nestedScrollingChildHelper.isNestedScrollingEnabled()) {
63.             shouldAcceptNestedScroll |= nestedScrollingChildHelper.startNestedScroll(nestedScrollAxes);
64.         }
65.  
66.         return shouldAcceptNestedScroll;
67.     }
68.  
69.     @Override
70.     public void onStopNestedScroll(View target) {
71.         super.onStopNestedScroll(target);
72.  
73.         if (nestedScrollingChildHelper.isNestedScrollingEnabled()) {
74.             nestedScrollingChildHelper.onStopNestedScroll(target);
75.         }
76.     }
77.  
78.     @Override
79.     public void onNestedScroll(View target, int dxConsumed, int dyConsumed, int dxUnconsumed, int dyUnconsumed) {
80.         super.onNestedScroll(target, dxConsumed, dyConsumed, dxUnconsumed, dyUnconsumed);
81.  
82.         if (nestedScrollingChildHelper.isNestedScrollingEnabled()) {
83.             nestedScrollingChildHelper.dispatchNestedScroll(dxConsumed, dyConsumed, dxUnconsumed, dyUnconsumed, null);
84.         }
85.     }
86.  
87.     @Override
88.     public void onNestedPreScroll(View target, int dx, int dy, int[] consumed) {
89.         super.onNestedPreScroll(target, dx, dy, consumed);
90.  
91.         if (consumed[1] == 0 && nestedScrollingChildHelper.isNestedScrollingEnabled()) {
92.             nestedScrollingChildHelper.dispatchNestedPreScroll(dx, dy, consumed, null);
93.         }
94.     }
95.  
96.     @Override
97.     public boolean onNestedFling(View target, float velocityX, float velocityY, boolean consumed) {
98.         boolean didConsumeFling = super.onNestedFling(target, velocityX, velocityY, consumed);
99.  
100.         if (nestedScrollingChildHelper.isNestedScrollingEnabled()) {
101.             didConsumeFling |= nestedScrollingChildHelper.dispatchNestedFling(velocityX, velocityY, consumed);
102.         }
103.  
104.         return didConsumeFling;
105.     }
106.  
107.     @Override
108.     public boolean onNestedPreFling(View target, float velocityX, float velocityY) {
109.         boolean didConsumePreFling = super.onNestedPreFling(target, velocityX, velocityY);
110.  
111.         if (nestedScrollingChildHelper.isNestedScrollingEnabled()) {
112.             didConsumePreFling |= nestedScrollingChildHelper.dispatchNestedPreFling(velocityX, velocityY);
113.         }
114.  
115.         return didConsumePreFling;
116.     }
117. }

В полезные коды не влазит никак

Android 7.1 with 25 SDK is available now for Android Beta program devices and official emulatorsПоехавшие что ли? Хватит штамповать!

aNNiMON, Вообще-то давно обнрвился до 7.1.1

Android Studio 2.3 Canary Available Below are highlights of some of the major changes in this release:

IDE: We've upgraded the base IDE from IntelliJ 2016.1 to 2016.2, which adds a number of new features -- ligatures, breadcrumbs, editor background images, revamped UI for inspections, notifications and the debugger, and more.
Layout Editor: The layout editor now supports chains and ratios for ConstraintLayout.
Lint now has "baseline support" which lets you check in a current set of warnings -- and from now on, only new issues are reported. This lets a project with a lot of technical debt set a baseline and then break the build only when new issues are introduced, without having to go and fix all existing issues first. In order not to forget about the technical debt though it creates an info-level issue which tells you that you've filtered out bugs:
WebP: Android Studio 2.3 now provides PNG to WebP Conversion. With the new conversion wizard, you can quickly generate WebP images and if you're using the lossy encoding, inspect the diffs of your images. Using WebP images in your app saves APK space and is more performant
Data Binding: In addition to a lot of bug fixes in the editing support for data binding, there is a new feature to help debug apps using data binding. Normally the IDE will automatically compute the data binding classes "on the fly" such that they are always correct and up to date with your edits in the XML files. However, when you are debugging your app, you may want to see and step into exactly the code that was compiled. You can now enable this under preferences.
Incremental SDK Updates: This version of Studio includes support for incremental patching of SDK components, such as system images. We can now provide patches for system images (which are often very large) and updating those with Studio 2.3 will allow a much smaller and faster download.
Build System: Support for the new Gradle plugin 2.3.0. There are some notable changes: The user cache for dex files is now enabled by default, which should speed up builds; Configuration times for very large projects should be significantly faster
Bug Fixes A notable & highly requested enhancement (b.android.com/220197) we also added is a search box to the Vector Asset Wizard You can now quickly filter through the vector icons based on the name of the asset. :raised_hands:

Не успел 2.2.3 обновиться, уже 2.3

Есть БД Realm в проекте. Ее инстанс можно получить через статический метод, т.е. это глобальный обьект.

Делаю запрос в методе или констректоре


Так вот а если вынести realmResults в поле класса, то колбек нормально вызывается.

Как такое возможно что как только теряется областт видимости результатов, то оно перестает вызывать листенер?

Может realmResults хранится где-то внутри либы как WeakReference?

Naik, да, похоже на WeakReference.
Как вообще Realm? Быстрее, чем SQLite? Много тянет?