Kostya,
I didn't have a chance to download the new build yet. So, I'd just respond to your latest question:
I think that the question (to resize or not to resize [and possibly, if you'd be kind to implement that here: to which size, as you already have it: large, medium, small]) should be asked at the time of attaching the images. And the resizing should be done at the time when the image(s) is(are) actually attached, so that saving a draft would be with the resized images.
This would be the best behavior.
(And it would be just one menu "Resize" with the items: {large, medium, small, do not resize}.)
Alternatively, if it is too cumbersome to ask for those size options, while still asking about resizing (yes/no) - the default size (if/when resizing) can be configured in the options. But this would be the second best.
With all of this, of course, the original images stored on the phone should not be modified. But that, I assume, is obvious.
PS. Sorry, maybe I've missed the point: why would one consider not resizing the image at the time when it is being attached?
Is that because of the uncertainty in the ultimate size of the message?
If that's the case, then maybe the menu with the choice(s) on how attach should contain an estimate for the total size of the attachments, for each option.
So, here a possibility of how this scenario can be implemented:
1. Click on "attach" (icon/menu item)
2. A pop-up window is opened offering to add an attachment to the list.
3. The object to be attached is added to the list of attachments in this window.
(no attachment is done yet)
4. The user has an option to add the next attachment to the list (leading to item 3. above) or to choose "attach".
5. Upon "attach", - the option for resizing is given, together with the estimates for the overall size of attachments for each resizing option (two options, yes/no, or 4+ options as suggested at the top of this message).
6. Objects are attached according to the option chosen.
7. A caveat: one might be attaching a mix of images and non-image files, so this should be handled accordingly, so that only jpegs are (1) resized and (2) that is properly counted in the estimate for the total size of all attachments combined.
8. Yet another caveat: What to do if after attaching images the user want to add more attachments. The possible choices are:
(a) To make it impossible to add any attachment, allowing to only replace them (i.e. delete all attached, and attach the new set). This would be probably easier to code, but not elegant.
(b) To treat the previously attached images as being attached already, so that
any additional attachments are done the same way, except that the estimate for the total attachment size is given with the addition of the already attached objects.
In essence, this way would allow one to mix attached images with different resizing options.
Kostya, please, forgive me for infringing into your territory and suggesting these possible scenarios.
