-
Notifications
You must be signed in to change notification settings - Fork 442
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
SDK is very Large (~8MB) and has a high method count #44
Comments
Thanks for the feedback! |
Yeah, a large number of methods can be an issue for some people. Is it bloating your final app's DEX size? If so, ProGuard (or some other minification tool) might get rid of a lot of the bulk. Many of the methods are for the DfB API, which isn't relevant to most Android developers. Are you running up against the DEX maximum method count? |
Yes, now I have to use multi Dex to compile my Android code because the v2 Java SDK adds too many methods. 19829 method count is almost one third of the 65k limit. I can image every Android app developer to be forced to use multi Dex if using this library. Interestinglt proguard is able to shrink the methods to keep it below the 65k limit, though it still adds about 10000 methods in my case, which I think is still too high for such a library. However, that's for the release build. I don't want to use proguard to obfuscate my debug code. I am still balancing the v2 SDK with multi Dex. It increases the apk size a lot, which I don't like. I really hope you can clean the code to reduce the method count. Thanks. |
@gemiren can you elaborate on which API endpoints you are using? Are you primarily using a few file endpoints, or you are using various team (i.e. business) endpoints? And are you accessing only a few fields from our responses or accessing every field (e.g. for display purposes)? I want to better understand your use case so we can take it into consideration for how to reduce the method count. |
@krieb thanks for look into this issue. My use case is actually very simple. I syncs my app data (settings & database, total about 5 files) to my app's folder on Dropbox. That's all I need. Just very basic Dropbox functions, no team functions are required. |
I am currently using beta 7 on android which has 11000 methods. The method count almost doubled in the recent versions. |
Android build fails when compile dropbox-sdk-java as a dependency to reach a 64k method count limit. And I found we have a lot of code handling object serialization & deserialization. What's the point handle these using a Jackson streaming parse API? Seems that every field has a I've tried fork the project to see if I can contribute some work, but finally I realise that the project is too complicated for me to make any change. Please consider use any |
@gemiren The method count should be slightly reduced now: Total: 12423 More importantly, however, the library is now much more ProGuard-friendly. You should see significantly reduced method counts if you enable ProGuard. If you don't want to deal with obsfucated code, you can specify the
This should cut the method count down to below 2000 depending on what endpoints you are calling. Additionally, the library no longer depends on jackson databind or annotation libraries, so that should help cut down on method count as well. The library has been heavily re-written to also be multi-dex friendly. @kirisetsz Unfortunately using annotations forces those classes to be loaded into the primary dex of an app if it is using multi-dex. This can blow-out the primary dex and prevent an app from compiling. It is a known bug in the dalvik platform that any RUNTIME annotation on a class/field/method/etc must be included in primary dex. This is the primary reason why the library cannot make use of annotation-based serialization. Also, using ObjectMapper in general requires special ProGuard rules to be used in combination with the library for code shrinking. This can often be error-prone, as previous bugs have shown. Finally, the massive jump in method count was due to changing all |
Nice to see a drop in the method count. It's much better, though it still has a large method count. Probably a better way to bring down the method count further is to break this SDK into multiple components like the Google Play service. For example, it can break into core, share, team, etc. That's going to make this library more flexible. |
Sample dex count graph via https://github.com/KeepSafe/dexcount-gradle-plugin. Dropbox accounts for 9558 methods. Big chunks are:
|
Any news about this? This library is too big!! I have just tried the 2.0.6 release and it has over 2000 methods more than 2.0.5 :-( |
@chrisonline There is no timeline set for splitting the artifact. In the meantime, we strongly encourage developers to use the standard android ProGuard configurations for their app development with this SDK. You can refer to the ProGuard section of the README to make sure you add the correct Let me reassure you that we are looking into strategies for distributing multiple artifacts to alleviate this issue. I just can't commit to a specific date yet. |
I stumbled upon the same problem, because my debug build hit the 65k limit. |
@krieb Hi! 1 Year later I want to ask about any news? ;-) |
FYI: Some time ago I have created an 'OAuth-only' fork of the Dropbox Core API. It contains only 226 methods. See https://github.com/litrik/dropbox-sdk-java |
@chrisonline I don't have any further news on this. |
Can we keep using v1 while this issue remains? When are you guys going to kill v1? |
We don't recommend using API v1 as it is deprecated, but it will continue working until it is retired. You can find the full timeline here: https://blogs.dropbox.com/developers/2016/06/api-v1-deprecated/ |
The current Dropbox-SDK-Java v3.0.5 method count is simply way too large for an Android library. Dexcount collected with https://github.com/KeepSafe/dexcount-gradle-plugin for v3.0.5: |
No news on this, sorry! We still recommend using Proguard. |
As mentioned above we should use ProGuard to optimize it. How can I remove this on release build to lower the Method count? |
@chrisonline I don't have an update on this, but I'll check in with the team. |
It looks that its never-ending story. I have currently 3.0.3 In my project, jar files have 3.5 MB. I was thinking about the update. The latest version is 3.0.11. I told great it should be just bugfixes. Then I realize that it has almost 8MB. Really? Especially on mobile devices, it is not an acceptable size. I'm expecting that 500kB must be definitely enough to upload and download files to some server. Especially when OKHttp is used. |
Version 5.3.0 is at These are the largest class files which are very, very large. This EventDetails generated source file is 1.8 MB uncompressed, and 40,000 lines long. https://github.com/dropbox/dropbox-sdk-java/blob/8b7d6b902a2394f0ef27ac53187ba388e6baf280/dropbox-sdk-java/generated_stone_source/main/src/com/dropbox/core/v2/teamlog/EventDetails.java |
This library needs to be shrink down. Currently it has 19829 method count which is way to large.
Below is the break down of the method count taken from http://www.methodscount.com/?lib=com.dropbox.core%3Adropbox-core-sdk%3A2.0.1
Library name: com.dropbox.core:dropbox-core-sdk:2.0.1
Total count: 19829
Methods count: 9087
Dependencies: 3
JAR Size (KB): 1897
DEX size (KB): 1214
Dependencies methods count: 10742
Dependencies JAR size (KB): 1503
Dependencies DEX size (KB): 1346
The text was updated successfully, but these errors were encountered: