AquaMail Forum
English - Android => Development builds => Topic started by: Kostya Vasilyev on August 21, 2015, 01:11:57 am
-
It's always hectic for a few weeks after a release, and use that time to work on the smaller easier stuff.
An often requested feature is to be able to resize (shrink) image attachments when sending messages, "like on the iPhone". Well, makes sense, most phones these days have cameras producing 6-8-12 megapixel images (and that's not all).
This feature requires some "native" code which is architecture specific, "arm", "x86", maybe "arm 64 bit" like the Nexus 9, so it adds up quickly.
So what I wanted to get opinions on is:
- Should I package this feature (and the libraries) into the app itself?
This would increase the .apk size by about 600K (for three architectures, "arm", "x86" and "arm 64 bit"), bringing the total size from ~5.3 MB to ~6 MB.
Install size overhead would be about 800K.
- Or split the feature into a separate app, keeping the main app's size down.
But then there are issues with discovery (another app? what is this thing?) and it's somewhat more complicated to code.
Any opinions?
Oh, and if add support for "x86 64 bit" later, the overhead would go to ~800K for the .apk / ~1200K for the "installed" size.
---
Note to @pyler -- yes, I'm aware that it's possible to build arch-specific .apk's, but it's just more hassle (and possibility for mistakes) when uploading to Play.
-
Hi Kostya
You asked for opinion so here it comes:
Aquamail became for a LONG time ago an advanced email app for all us users who needs and wants more than an ordinary standard email app do (like most stock email app). This you have managed WITHOUT forgetting also those "less advanced" users who dont need all the features that it brings. But then to be honest...for being the app it is today IT IS SMALL IN SIZE and I have always wondered how you managed this ;-)
But I think most people would agree that to get included more features, especially important ones like image handling, is well worth an larger image size of the app.
I will admit, with no shame that I used before Maildroid which is also an amazing email app, and the reason for my choice that time was all the various functions/features it brought me and the size of the app in that time was 10.2Mb AND WELL WORTH IT.
They had even a thing that I for a VERY long time now hoped that Aquamail also could reconsider one day: temporary image resize for INLINE PHOTOS...which means...when you insert an image in the mail, it doesn't touch the original size when u send the mail, but makes a thumb, (saying the original size) so your email doesn't get distored while continue writing. The reason this is a INCREDIBLE feature is that the person who receive the email in for example a computer doesn't need a magnifying glass to see the pics inserted in the mail as it is today with Aquamail. It even send and show animations of gif files for the same reason: it sends it in the original size.
So to summarize: I would absolutely support an increase in filesize in change for more features.
And just to avoid misunderstanding: I LOVE AQUAMAIL AND WON'T CHANGE TO ANY OTHER APP FOR ANYTHING ;)
-
Thank you Julio.
Yes, there are much, much larger apps these days (especially those with material design on older Android versions, but not just that).
And then I guess you're saying that 5.3 megabytes -> ~6.1 megabytes isn't much (more when installed, but still). Point taken, thanks.
-
Hi, EWS Active sync and speech mode pls.
-
Maybe it is possible do it in "plugin/addon" style?
I will personally not use this feature, I send high res photos when needed :D but it is quite questionably how many will/will not use this feature. I am sure 600k will not kill everybody, but.. I remeber days we have 3,5mb apk size :D
If high demand, integrate it. If not so high, plugin is better choice I believe.
Pretty surprising you are going to work on this, since there are more wanted features :D joke =D
-
Aquamail users have a medium top devices, in my opinion, so it is not a problem to increase the app weight.
The difference I appreciate is the big customized setup, I think Aquamail can have share with this strategy.
Thanks
Phone: Galaxy Note 4
Watch: G-Shock Gulfmaster
-
Please add conversation view!!!
-
An optional plugin would be my personal preference. But if it's much simpler to Include it in the app by default and you feel you have the demand for it, then put it in the app. It's not a huge increase in size, and it is kind of a good feature to have.
Android since v1.0. Linux since 2001.
-
I fully agree with Julio 66. 6MB is far away from being super heavyweight and going for a plug-in approach would complicate things only to save 600k... So, I personally do not care about app size as long as the app itself is responsive. Above that, I would consider this feature as useful (as well as conversation view ;-) ).
-
Add font Verdana, EWS active sync and conversation view please.
-
I feel if this feature could be offered as plug in, which can be installed if some one choose to install by pressing some button in setting menu.
As you may add other feature too in coming days
-
I think this could be added without a problem the goal should be to keep it under 8 to 10 MB otherwise will reach the point to be as big as any other app and the idea is not only to be better but to be an small and efficient app
Also if there is a chance could you please make one for windows phone too
Raps
-
They should be just menu item. If plugin is installed, menu item will be enabled/shown.
If somebody changes phone.. not a big deal, Google Play automatically installs all your apps in your new phone. So plugin too.
-
Thank you, thank you, thank you all.
-
Sorry for the delayed response: this thread has sprang very quickly, while I was traveling.
1. One has to keep in mind that the size that Kostya mentioned (5-6 MB) is the packed, and not installed one. The latest Google Play version installed on my phone weighs 9.52 MB, as reported by the system (Settings -> apps).
It is still a very reasonable size. In comparison, the behemoth Chrome unpacks from 31 MB
to 99 MB, and because it is a part of the bloatware installed on my phone by Verizon, I have no way uninstalling it without rooting the device. (In reality, it takes 112 MB, because you cannot stop it, and the moment it starts, it stores 13 MB of data. Deleting that data doesn't last for too long: some seconds or minutes.)
2. Some users do have "the latest and greatest" phone models, but some people do not. E.g. I have Droid Razr M that I am mostly happy with (it is compact and does what I need). But it has only 8 GB of memory built in, and Motorola/Verizon modified system that doesn't installed allow apps to be installed on the external SD card (even those that are app2sd). Also, some apps and parts of the system are hardwired to save their information on the internal storage, and cannot be configured otherwise (e.g. screenshot, file download, ...)
Because of how Android handles the internal space (or how it is configured on this phone), - essentially only about 4-5 GB is allocated to apps and storage.
Some of my associates are using cheap budget-type "Made-in-China" phones with probably 4 GB (if not 2 GB?) of internal storage, and then the space is even more valuable.
I do have a 32 GB miniSD card - I store all the photos and videos there, and move the files there whenever I can.
I am keeping the OS version on 4.1.2, avoid the update to 4.4.x (KitKat), - for a combination of reasons, including the limitations with respect to the SD usage/permissions.
I do have a bunch of apps installed: web-browsers, navigation (Google Map, Waze), travel (TripAdvisor, Kayak, Yelp, "My" airlines), communication (Skype, Viber), developmental games for my kid (reading, math, etc. - those are usually large, 20-50 MB each). Together with the preinstalled bloatware that is disabled but cannot be deleted, they take close to 3.5 GB.
As a results, the "available" space (for the system and apps) varies from about 460MB (when the OS starts complaining about being short on storage and that some functions might not be available) to 600 MB, - depending on how much space is used by cache and data. When I am doing an update for the larger apps (e.g. TripAdvisor), - I must clean all the cache, to have sufficient space for the update to be installed (downloaded apk, overhead space [unpacked app or whatever it is?]).
The nice thing about Aquamail is that I can update it without much hassle with the storage space.
If and when I need to install some new app, I must maintain the space balance, and usually delete some apps that are not used frequently.
For all these reasons, - I am happy that Aquamail has a very modest footprint.
3. Image shrinking functionality.
I think it is a good feature (that some of my correspondents would benefit from, - but then again, many of them are not using Aquamail). However, I'd like to warn about the potential evil side of it: Some iPhone users do not realize that the images they send are reduced in size. Just recently on the photography list that I read, there was an issue that a guy was receiving pics of his recently born grandchildren at the reduced resolution that was marginally [in]sufficient for printing, and his daughter had no clue about that. And, of course she had no idea how to send the original image.
And earlier, I've heard about someone else, who assumed that the images were preserved in the e-mail that he sent to himself, and deleted the originals.
I hope, Kostya, these two stories would be helpful in how you will design the configuration of the image-resizing options.
4. Personally, I am happy with the functionality that QuickPic offers for resizing.
So, for me, the convenient option would've been to have the same type of "filter" for attachment that presently exists for the inline image, -- namely, opening the image(s) in QuickPic and configuring how it should be resized. Unfortunately, AFAIK, QuickPic doesn't offer "batch-resizing" option. (As a reference, - imageMagick library does that type of job well on Unix, but I haven't tried its port on Android)
I am not 100% sure if I'd be installing that option for Aquamail or not, - it depends on the implementation/functionality. So, for the flexibility of not installing it if I don't need it, - I'd vote to have it as a plug-in.
5. Just in case, - I've seen an app (Tiny Flashlight + LED) where the developer decided to go modular, with the plugins after some long period of time of having his (rather popular) app. That did make the base app small in size. (And I appreciated it, as the original app was rather large in size). But the change broke what people got used to. As a result, there were quite a few whiners who were unhappy, giving ultimatums in the feedback. After just a few months he switched back, to an all-in-one app. (I didn't update it.)
The moral of the story: people are happy to be unhappy with seemingly drastic changes, no matter what.
6. I agree with others (Pyler, ..) - who proposed this functionality to be an option in the settings menu that calls for plug-in to be installed.
Kostya, I hope these thoughts are helpful to you in making the decision(s).
PS. And yes, please, make the font BukaZyaka size 9.82 available. ;D
(In plain-text mode, of course! Please!)
-
Definitely resize photos that are sent via email, perhaps the option to attach the full size or option to attach much smaller size.
-
I do have a bunch of apps installed: web-browsers, navigation (Google Map, Waze), travel (TripAdvisor, Kayak, Yelp, "My" airlines), communication (Skype, Viber), developmental games for my kid (reading, math, etc. - those are usually large, 20-50 MB each). Together with the preinstalled bloatware that is disabled but cannot be deleted, they take close to 3.5 GB.
As a results, the "available" space (for the system and apps) varies from about 460MB (when the OS starts complaining about being short on storage and that some functions might not be available) to 600 MB, - depending on how much space is used by cache and data. When I am doing an update for the larger apps (e.g. TripAdvisor), - I must clean all the cache, to have sufficient space for the update to be installed (downloaded apk, overhead space [unpacked app or whatever it is?]).
[...]
4. Personally, I am happy with the functionality that QuickPic offers for resizing.
It is not very easy to fulfill you're needs, as you're using a phone with not that much free space although you're using a bunch of apps that eat up the space. In the end you're vote is to not extend AquaMail with a good functionality, but rather install another third party app to have this functionality.
Result: More apps, more clicks (touches), more space used.
-
Request: edge screen lighting up... :o 8) Pleaaaazzzzeeee....
-
It is not very easy to fulfill you're needs, as you're using a phone with not that much free space although you're using a bunch of apps that eat up the space. In the end you're vote is to not extend AquaMail with a good functionality, but rather install another third party app to have this functionality.
Result: More apps, more clicks (touches), more space used.
@beerlao:
As far as I understand StR is voting for a "plug-in" solution... not to install another third-party app
6. I agree with others (Pyler, ..) - who proposed this functionality to be an option in the settings menu that calls for plug-in to be installed.
.
-
Summarizing all the posts - and my own thoughts indeed - I'm tending to prefer a plug-in solution.
I suppose the handling could be something like the "Threema Voice Message plug-in":
> see attached screenshot:
"YES" is a direct link for downloading the plug-in from Google's Play Store ...
Thus, the option "Resize image(s)" would always been displayed (... when attaching images) but the user has to install the plug-in first for using this feature.
This solution could satisfy most users.
-
In this could everywhere age, I doubt somebody sends his/her tons of vacation photos via mobile email apps. But ofc, I have no really usage data or data of most wanted features but this is my opinion.
Btw, Kostya, Is resizing via Java code impossible? or will it take ages?
-
@mikeone, too complex. Users will rate 1-star the app.
Many users don't like regressions, changes,... See TypeMail, a large size app, but with very good rating. Gmail is large, many games are huge, I'm confident that the size (+1 or +2MB) does not matter, for all users. It's less than 1 picture size ;)
I don't think that this procedure will be too complex for the user (but maybe for Kostya - I don't know), since the necessary installation of this plug-in has to be done only once... with just two "clicks": "YES" > "Install"...
Personally, I have no concerns about too large app-size - neither pure apk file nor the installed size -.
On the other hand I think it could be a nice solution if users are able to customize the app's additional features (*) depending on their own needs.
(*) e. g.:
- Image resizing
- Message translation
- ...
-
Yes, in app translation for messages. But low priority, vey low for Kostya.
Maybe Kostya can just add dedicated option "Translate" which basically shares app text to Google Translate or similar app. Saves click or two :P
-
... not always but even more often. 8)
-
Some Spanish/Italian spams or so :D :D
I already suggested to create "uservoice" (simple poll like) page where they can vote what they want to see in AquaMail. Unique features make app famous :)
-
Some Spanish/Italian spams or so :D :D
I already suggested to create "uservoice" (simple poll like) page where they can vote what they want to see in AquaMail. Unique features make app famous :)
Hi Pyler,
Good idea. However, I recommend this should done only after conversation mode... :)
-
Uservoice is just a mechanism, nothing more, it's not going to magically write new code, fix bugs, or provide support (which takes a lot of my time).
I had a "suggestions" section here and closed it down because I couldn't keep up.
My big priority is conversation / threading, and image resizing is a little side project while dealing with the fallout from the 1.5.9 update.
Perhaps I should clarify: every "major" update causes an avalanche of emails from users:
- Questions, suggestions
- "Why did you have to fuck up your app"
- "TypeMail and CloudMagic can do X and MyMail can do Y, and you and your app are pathetic"
- "My Yahoo account doesn't work anymore, fix immediately"
- "My corporate mail system was upgraded, what are the new settings"
- Many people think it's the right time to ask about some pet feature "how about moving that menu item up, above that other menu item"
It's pretty much impossible to work on anything "significant" when it's hectic like that.
So I use this time to work on smaller, easier, self-contained projects.
This time it's image resizing, which has an impact on the app's size, and I wanted to get opinions on how to best package it. Thank you everyone who's responded.
I did not mean that this is the only future feature that I'm considering or ever going to implement.
-
@pyler
In this could everywhere age, I doubt somebody sends his/her tons of vacation photos via mobile email apps. But ofc, I have no really usage data or data of most wanted features but this is my opinion.
Apparently a lot of people do that.
And apparently they "absolutely will not" change their camera settings to some reasonable image size to begin with.
Btw, Kostya, Is resizing via Java code impossible? or will it take ages?
It's not about performance, it's about memory usage.
With Android Java APIs, an image has to be fully loaded (all pixels, as if for rendering) and then you can resize by making a new image at the smaller size, again, fully in memory.
Let's see -- an 8 MPx original needs 32 megabytes of memory.
An 2048*1024 (approx.) output image needs 8 megabytes.
And then there are devices that have 12 Mpx cameras, maybe even 16 Mpx or more.
( yes, I know you can down-sample by a factor of two while loading, but that's still a lot of memory and may not give good quality )
With native code, it's possible to decompress one scan line at a time, compress one scan line at a time, and the actual resizing code only buffers a few scan lines at a time, just enough for filtering.
That makes for hugely lower memory usage, and I don't have to worry about next generation phones with I don't know, 20 Mpx or 24 Mpx cameras.
-
@pyler
In this could everywhere age, I doubt somebody sends his/her tons of vacation photos via mobile email apps. But ofc, I have no really usage data or data of most wanted features but this is my opinion.
Apparently a lot of people do that.
And apparently they "absolutely will not" change their camera settings to some reasonable image size to begin with.
Btw, Kostya, Is resizing via Java code impossible? or will it take ages?
It's not about performance, it's about memory usage.
With Android Java APIs, an image has to be fully loaded (all pixels, as if for rendering) and then you can resize by making a new image at the smaller size, again, fully in memory.
Let's see -- an 8 MPx original needs 32 megabytes of memory.
An 2048*1024 (approx.) output image needs 8 megabytes.
And then there are devices that have 12 Mpx cameras, maybe even 16 Mpx or more.
( yes, I know you can down-sample by a factor of two while loading, but that's still a lot of memory and may not give good quality )
With native code, it's possible to decompress one scan line at a time, compress one scan line at a time, and the actual resizing code only buffers a few scan lines at a time, just enough for filtering.
That makes for hugely lower memory usage, and I don't have to worry about next generation phones with I don't know, 20 Mpx or 24 Mpx cameras.
Kostya....10 points for this TOTALLY PERFECT AND TRUE reply:
And...to add something....MORE AND MORE people ARE using their phones INSTEAD of their computers...even for sending photos, so this is absolutely an actual, important and VERY USEFUL new feature.
Then to not forget the most important: Kostya is developing an email app for PHONES...not computers...aka...he needs to think of the users of the phones...and then I mean us people THAT ONLY USES PHONES and no computer...which Kostya has done so excellent until now...
Kostya...You show so clearly that you understand and knows the need and requirements a phone user has today....THANKS A LOT FOR THAT...keep up that good work, and a small suggestion: looking at THE AMAZING email app you have developed until now...start trusting your own judgment of needful features.
I know you ask us users for opinion to let us be a part of the development but with small additional features you should just DO IT with the belief that an increase of the filesize this small is not significant at all.
Hopefully I didn't misunderstood you Kostya, but didn't you ask for our opinion regarding the image resize feature???
If so...don't let us drag out this tread with our wish list of new features...remember what Kostya said....we had a tread with a "wish list" but its closed and the reason given....so....
I almost beg you Kostya to not start "screwing things up" by start adding "add-ons" to the app, because we all know that this is the reason too many people look away from the apps where they need to start installing plug-ins with their first use....people wants effectiveness, simplicity and beauty in an app and until now THIS IS ALL AQUAMAIL!!!
Keep it up Kostya, you still have a lot of MB to go on ;)
-
Thanks Kostya
I will vote in support of more features
Sent from my SAMSUNG-SGH-I747 using Tapatalk
-
I'm almost done with the better image resizing UI (the compose window).
-
That looks great.
Better solution (estimated size in AquaMail) than this one (resolution in Threema):
:P
-
In AquaMail it's also driven by image sizes, original vs. size "buckets" (max. 2048 / 1280 / 768)...
...but the dialog gives you size *estimates* so you can decide.
Oh and by the way, "large" is really the only one anybody would need --
1 - big size reduction relative to typical camera rez (8, 12, 16 Mpx)
2 - still large enough even for FullHD displays / TVs
But the "medium" and "small" will stay just in case...
-
In AquaMail it's also driven by image sizes, original vs. size "buckets" (max. 2048 / 1280 / 768)...
...but the dialog gives you size *estimates* so you can decide.
I agree with the idea mikeone (if I understood him correctly), - that was my own reaction as well, but let me rephrase his suggestion.
I'd say that maybe showing explicitly (even if in a smaller font under each option), - the images sizes in pixel, in addition to the estimated sizes in bytes would be helpful. Maybe those sizes should replace the words "small", "medium", large"?
I.e.
Shrink images
- Do not shrink (17MB)
- 2048x??? ( ~ 2.5 MB)
- 1280x768 (~ 0.99MB)
- 800x600 ( ~ 364KB)
or
Shrink images
- Do not shrink (17MB)
- Large, 2048x??? ( ~ 2.5 MB)
- Medium, 1280x768 (~ 0.99MB)
- Small, 800x600 ( ~ 364KB)
I remember your arguments that not mentioning those explicitly helps to be able to change them later. But when I am sending my images (resizing with QuickPic), - I am choosing the options based on (1) the intent (e.g. to be able to see the detail "A", but just on the desktop monitor -> 1280x768/1024x768) and on (2) my connectivity (e.g. I am in Argentina with extremely limited and expensive traffic allowance, but just need to pass the overall view of an item ASAP -> 800x600 or 640x400). So, knowing the size in pixels helps (1), knowing the estimates size somewhat helps (2).
But I haven't seen the -6 build yet, so, maybe you've already implemented that...
Oh and by the way, "large" is really the only one anybody would need --
1 - big size reduction relative to typical camera rez (8, 12, 16 Mpx)
2 - still large enough even for FullHD displays / TVs
But the "medium" and "small" will stay just in case...
Great! The smaller ones can be handy for the reason (2) above.
PS. And I like the implementation of this feature, - so it is growing on me. My previous doubts of how much I'd use it myself are melting: in some situations, especially for very quick mailing, it will be more convenient than to use QuickPic.
However, if possible, please still keep QuickPic option available: it allows cropping the image in addition to resizing.
-
@StR -- given that you are one of the privileged few, and *know* the exact size buckets ( 2048 / 1280 / 768 at the time, but ssshhh!), is this really necessary?
Just to summarize / simplify things:
- Large is the only one "truly good enough" for any desktop monitor (ignoring the not so common yet 4K ones), so use that if necessary, and the (byte) sizes are acceptable
- Medium and small may not be optimal for "big" computer viewing, so use them if your connectivity is slow / expensive.
-
@StR -- given that you are one of the privileged few, and *know* the exact size buckets ( 2048 / 1280 / 768 at the time, but ssshhh!), is this really necessary?
If that wasn't a rhetoric question, my opinion, - yes, people appreciate knowing it, and most apps that resize images show the size in pixels. So, many users expect it that way even if some might not really understand how to use that information.
Besides, even if the sender him/herself doesn't know the difference, those who ask them to choose the "right" option, get frustrated when the options are not labeled.
- Next time, could you please send those photos reduced in size?
- ...
- ...
- What option should I use: Large, medium, small?
- What's that in pixels?
- I don't know, it doesn't really say anywhere...
- Argh!... And you told me your mail program is cool? #$%^&! ... Any self-respecting program that does image resizing should say what those sizes are... (even if it doesn't save .eml)
8)
BTW, as for various ways of using things: So far, I haven't sent from my phone any resized image larger than 1280-ish. But I am very untypical in this regard.
-
"Any self-respecting mail app"
"What is the size in pixels".
I'll bet you dollars to donuts that ordinary users don't know what those pixel things mean.
"I thought you said that your mail app was cool, what is that, 2048, oh, I remember, it's a puzzle game, wtf?"
And let's not forget Apple, well known for their elegantly polished interfaces.
https://www.aqua-mail.com/forum/index.php?topic=3907.msg20299#msg20299
-
Kostya, I agree with you in regards to how much an "ordinary" user knows.
I made my suggestion and provided my arguments. It's your decision what you choose for your app.
But since you mentioned it, I've been wondering for a while: do you have some idea about the percentage of "ordinary" users and "geeky" users [whichever way that is defined (^)] among Aquamail users? I wonder if those are quite different from the corresponding ratio for all Android users.
----------
(^) including the users who have limited technical understanding but think they are geeky.
-
No, I don't know.
I do know that
1) this forum's regulars are very technical, not necessarily software developers or hardware architects, but whose brains work well with technical concepts.
2) right now, I'm teaching someone (over email) about his Samsung's Menu button and how to press it to bring up the menu.
A vast distance there.
-
conversation view pls........
-
http://www.aqua-mail.com/forum/index.php?topic=3873.msg20067#msg20067
-
@qwerty1q:
"Sometimes" using the forum's search function could make sense ... 8)
-
Dear Kostya,
I have a following suggestion: please use uservoice.com for user suggestions and feature requests!
Right now, user suggestions for Aquamail are not handled properly. The feature request forum is closed (read-only), since July 2014. You ask users for their feedback only on an ad-hoc basis (this thread).
In short, here is what uservoice.com can do for you as a developer, and for us users:
- we can post our suggestions (you can also post suggestions)
- you can easily rate (categorize) user suggestions (working on it / planned / completed / declined)
- both you and us can post comments (just like in this forum)
- users can vote for suggestions, so you can prioritise between requests / suggestions
If you want to see how it works in practice, here is an example:
outlook.uservoice.com/forums/293346-outlook-for-android
I know, uservoice.com is not for free ($15/month). But i believe it is worth the money.
-
http://www.aqua-mail.com/forum/index.php?topic=3873.msg20067#msg20067
Dear Kostya,
I have a following suggestion: please use uservoice.com for user suggestions and feature requests!
Right now, user suggestions for Aquamail are not handled properly. The feature request forum is closed (read-only), since July 2014. You ask users for their feedback only on an ad-hoc basis (this thread).
In short, here is what uservoice.com can do for you as a developer, and for us users:
- we can post our suggestions (you can also post suggestions)
- you can easily rate (categorize) user suggestions (working on it / planned / completed / declined)
- both you and us can post comments (just like in this forum)
- users can vote for suggestions, so you can prioritise between requests / suggestions
If you want to see how it works in practice, here is an example:
outlook.uservoice.com/forums/293346-outlook-for-android
I know, uservoice.com is not for free ($15/month). But i believe it is worth the money.
-
RavenSoft:
Thanks for the link to Kostya's statement. It's truly clear and reasonable..
Mikeone
-
Features!
Sent from my SM-T330NU using Tapatalk
-
I would favor a plug-in. My reason is simple: I have no need for it. For a long time I've used "Image Shrink lite" from within Aquamail whenever I send an image. It works fine, has several on the fly size options, and integrates well with AM.
Maybe the Aquamail version would have advantages. I don't know. But for me personally, ISL has solved my image sending problem for a long time.
Just my 2 cents. (I hope it is OK to mention another app here).
-
Someone needs to wake up: image resizing has been implemented already.
(And as for plugin vs. in-app, - while I had initial slight preference toward the plugin, - I am happy with the way Kostya has implemented this feature the way he did.)
-
Someone needs to wake up: image resizing has been implemented already.
(And as for plugin vs. in-app, - while I had initial slight preference toward the plugin, - I am happy with the way Kostya has implemented this feature the way he did.)
😂😂
and yes, Kostya is usually (if not always) on the right way with his decisions. 👍
-
Someone needs to wake up: image resizing has been implemented already.
(And as for plugin vs. in-app, - while I had initial slight preference toward the plugin, - I am happy with the way Kostya has implemented this feature the way he did.)
Yes it just appeared in the update I downloaded yesterday. I turned it off for now because I'm so accustomed to using image shrink lite, but I'll give it a try later.
Fwiw, I only read this forum from time to time. Some of us have a life. ;)
-
Fwiw, I only read this forum from time to time. Some of us have a life. ;)
Oh, you have a life....without AquaMail. Really 8)
Kindest regards
Mikeone
-
I'am using my smartphone as a smartphone and not for a cam, and that's what an emailapp should provide. I would like if there come rules and encryption. Thanks Kostya for your perfect work.
Sent from my mobile.
-
I'm currently working on message threading.
Re: rules -- it continues to be my belief that message filtering is best done on the server.
-
Thank you for the chance to comment on the integrated function vs plugin situation.
Please bear in mind that I'm only a new user of AquaMail,so I'm not up to speed on all the past history.
I'm more than happy for the aforementioned functionality to be integrated into the app, including the additional filesize that will accompany such a decision.
As I see it, core/key functionality that is to be expected of an (email) app should rightly be integrated into the app itself.
For those extras however, non-core, yet useful, additions could be placed into a single, separate plug-in. This single plugin could house all current and future additions and features, and allow only those users who are interested in said features to opt-in (for the additional resource cost: size, etc).
This would keep the main app as slim and core-featured as reasonably possible, while not preventing more 'exotic' (yet reasonable) functionality for those who require it.
Having a single plug-in (which houses all extras) might also make (future) development easier (once the initial plugin framework was included).
[I'm not a dev, so I admit that I have no idea how difficult implementing a plugin system would be, nor if it would be worth the effort]
Regards,
J
-
This would increase the .apk size by about 600K (for three architectures, "arm", "x86" and "arm 64 bit"), bringing the total size from ~5.3 MB to ~6 MB.
Install size overhead would be about 800K.
[...]
Oh, and if add support for "x86 64 bit" later, the overhead would go to ~800K for the .apk / ~1200K for the "installed" size.
Kostya, thanks for seriously considering of the impact on users with older phones and limited resources. I installed AquaMail in the first place because it fit and ran well on my little phone. Half a megabyte might seem like nothing to people with recent hardware, but for some of us, it is the difference between being able to install an app and not being able to.
I don't need the image resizing feature, so making it a plugin seems preferable to bloating the app. I'm sure people with capacious devices will feel differently. Whichever approach you choose, I hope you'll keep making these decisions carefully in the future. Some of us really do appreciate it.
-
Image resizing shipped a couple of months ago, packaged in the app itself :)
I'm now getting ready to post the first -dev build with threaded messages, hopefully in a few days.
So far, threading has added about ~30K to apk size.