samarthd / futuremessengerapp

A free, open source, ad-free app for Android that allows you to schedule SMS messages ahead of time! Just schedule a message and it'll be sent automatically at the requested time! Version 2 developed by Samarth Dhruva. Version 1 developed by Samarth Dhruva, Billy Do, and Arthur Storey.

Future Messenger

A free, open source, ad-free app for Android that allows you to schedule SMS messages ahead of time! Just schedule a message and it'll be sent automatically at the requested time!

Version History & Downloads

Version	Developers	Release Date	Notes	Download	Android Version Requirements
1	Samarth Dhruva, Billy Do, and Arthur Storey	August 14, 2016	Created as part of the Summer 2016 CS371m Mobile Computing class at UT Austin, taught by Michael Scott.	Version 1 APK Download	Android 4.2+, AKA API 17
2	Samarth Dhruva	October 28, 2018	A full rewrite from scratch, with UI and functional improvements.	Version 2 APK Download	Android 5.1+, AKA API 21

Why is it open source, free, and also ad-free? What's the catch?

No catch. This app was really just supposed to be a good learning experience for me, and I don't feel right about ruining the user experience with ads or charging people money for an app that has such a niche use case. It's open source because I personally enjoy open source software and I've got nothing to hide from my users! I want to have their trust when they use it!

Why isn't this on the official Google Play Store?

Great question. The answer brings up a sore spot for me, but I'm happy to divulge the history of this app.

• Originally, the app was on the Play Store at this link, which is now broken, for about a year and a half. We even had a nice web advertisement for the app, which is still up as of October 28, 2018. Then came the massive sweeping Play Store policy changes in February 2018 due to the Facebook Cambridge Analytica scandal, and because I was too busy with school to draft up an official privacy policy for the app to comply with the new requirements, it was removed from the store.

  • Note: The app never did (and still doesn't) collect any information, and stays entirely offline and local to your device - trust me, I'm a privacy nut and would be as skeptical as you. The Play Store policy changes required me to specifically update the app's Play Store listing with an official statement about how I handle user data. This, like I said, I was too busy to do, and thus it was removed. There was never any dispute over the actual behavior of the app. And if you don't believe me, you don't have to! Just look at the code yourself and verify my claims! It's open source, I've got nothing to hide. 😊

• On July 6, 2018, I started working on a full rewrite of the app (Version 2), as part of a recommitment to Android development after I got out of school. My plan was actually to finish version 2 and then put it back on the Play Store with full compliance to the new policies! I had gotten about two months into the development of it, when news broke about unsecured Google+ APIs potentially leaking user data.

  • As part of the effort to manage the PR nightmare, Google launched Project Strobe, a set of measures to regain user trust, including shutting down Google+ and some policy updates for Android developers!

  • Here's a quote from Google:

    • Finding 4: When users grant SMS, Contacts and Phone permissions to Android apps, they do so with certain use cases in mind.

    • Action 4: We are limiting apps’ ability to receive Call Log and SMS permissions on Android devices, and are no longer making contact interaction data available via the Android Contacts API.

    • Some Android apps ask for permission to access a user’s phone (including call logs) and SMS data. Going forward, Google Play will limit which apps are allowed to ask for these permissions. Only an app that you’ve selected as your default app for making calls or text messages will be able to make these requests.

  • Another more detailed look at permission requirements is found here.

    • Activity: Your app manifest requests the SMS permission group (e.g. READ_SMS, SEND_SMS, WRITE_SMS, RECEIVE_SMS, RECEIVE_WAP_PUSH, RECEIVE_MMS)

    • Requirement: It must be actively registered as the default SMS or Assistant handler on the device.

  • This meant that my app was now in violation of Google Play's policies for its core functionality! Future Messenger cannot (and was never intended to) function as a complete SMS app, it's just a scheduling/sending utility! It needs the SEND_SMS permission in order to automatically send messages! I was super defeated when I heard the news, but I decided that I wouldn't let my hard work completely go to waste. I finished up the app and put the .apk (linked above) on GitHub so any lone wanderers (like yourself) could still download and use it.

• At the time this is being written, the permissions requirements are purely in the policy of the Play Store, and there is no hard code-based enforcement of permissions in Android. This means that you can still download the app from the links above, and it'll work for you. It has been tested to work properly on all versions of Android from 5.1 (Lollipop) to 9.0 (Pie). Future versions of Android may hard-enforce the aforementioned permissions requirements and thus the app may not work on them. Until then, though, enjoy the app, and feel free to hit me up if you have any comments/feedback! 👍

Screenshots

futuremessengerapp's Issues

Add support for multi-recipient sending (including group/not group) options.

Change the icons on the floating action buttons.

The "Email" icon needs to be replaced.

Officially support API level 23

Setting target SDK at 21 allows phones at 23+ to send messages, but we should officially support that SDK by having runtime permission checks.

Images larger than 4098 width/height (or 2048 on some devices) do not load

Need to scale image down before setting them.

Instead of the phone input field, use the contacts list to send messages.

This is a big task that needs to be completed.

Implement edit message backend with database

Ensure that once the MMS message is sent off successfully, we delete it from the database and clear the picture from our directory.

DatePicker does not save date

f0f8dba

Incomplete methods.

Add an About screen

I think it'd be useful to have some info about how to use the app and the different behavior we expect for MMS vs SMS (due to push notifications and whatnot )

Add some animation to the list view population

See if it can be made prettier

Populate from preset doesn't work in MMS activity

It is likely due to the fact that MMS activity overrides onActivityForResult() which means it doesn't respond to the stuff EditTextMessageActivity is waiting for. It's possible that calling super.onActivityForResult() in the override could fix the problem. Probably set that as the default case, because we don't want the super method's cases to be triggered and then drop to our activity and do another thing. We should check our cases first, then call super.onActivityForResult().

Use a fragment to ask the user whether they want a message to be sent as a group/individually.

When they click the schedule button, check the count of numbers/contacts--if the number is greater than 1, present the fragment.

Check that presets aren't empty before saving them.

It's currently possible to save a preset with a blank name and content.

Make the main screen prettier.

The basic "Currently scheduled messages" text with the uninteresting listview is ugly. Update it.

Add a formatted date/time column to the database.

This is the one that should be displayed to the user. Make sure to check for updates to the regular column and update the formatted one accordingly.

Add error checking to ensure that all fields are filled out before a message is scheduled.

Make the message edit/delete menu appear on short click as well as long click

Right now it's not really apparent. in addition, maybe we should change it from being a fragment pop-up and use something that's closer to the app bar overflow menu style.

build.gradle file says minSDKversion is 15

I thought this was changed when we met. Not a big deal now, but something we maybe want to make sure is set properly by the end of the project.

root_folder/app/build.gradle is where the file is at.

Remove the random log prints in the code

I left some miscellaneous log messages in the code that weren't formatted properly. Need to remove them.

Change the current fillListView() query to the commented version.

The current one will return every message/recipient pairing as individual rows but the commented version will build strings of all phone numbers so we can display them in our view easily.

I think the order by also needs help but it's all basically there.

Figure out what should be done in the event that inserting a message or recipient into the database returns -1.

If you're entering a bunch of recipients and suddenly one of them fails, do you go back and delete all of the stored recipients and the message you stored already? Hmm....

Finish implementing skeleton code for screens and menus.

At least get some activities started from each of the menus and have those activities actually created.

Get database working and set up.

Currently there's not really a database in place for storing message details.

Fix the runtime error that arises when SimpleCursorAdapter can't find a column called _id

Apparently your table needs a column called _id for it to work, and it's not finding it. I think this can be solved by just making your own adapter, but there may be another solution.

http://stackoverflow.com/questions/3359414/android-column-id-does-not-exist

Figure out how to properly query for all recipients of a message.

Currently we have two tables and an association table that kinda joins them, but I have no idea how to properly mix them. I especially don't know how we would retrieve the data columns of each recipient/message.

Implement delete message backend with database

Change edit text set error string to something else

Like "You can't leave this blank"

Delete the TextMessage class and the Message interface if they aren't necessary.

They seemed useful at first but they might not be after all.

Crash: If MainActivity is open when text message is sent, view is still there. Attempt to edit the deleted view will crash the app.

Alarm sends same first message multiple times

Alarm works the very first time, but sends the same message over when trying to do a second message.

Figure out how to send SMS.

Add the app icon to the main activity's action bar.

It literally shows up 0 times in the app, so the users never associate the launcher icon with our actual app.

Restrict date/time picker to not allow date/time before current.

http://stackoverflow.com/questions/18272306/set-limit-on-the-datepickerdialog-in-android
http://stackoverflow.com/questions/13516389/android-timepickerdialog-set-max-time

See if there's a better way to build the Time string?

Find a way to gracefully handle messages that are too long. Break them into multiple messages.

Currently, the sending will just fail.

Make the EditMessage screens look more like the wireframe versions.

They're very plain as of now. Update them.

Make the query to the database occur in the background.

I think right now it's done in the UI thread.

Replace transmission success/failure toasts with notifications.

Perhaps add functionality to reschedule a message on failure by clicking the notification.

Review the EditMessage CardViews and make sure everything is identical.

Was totally sleep deprived when making them, make sure they're actually the same style and all.

Implement list-setup for building the contacts list from an "Edit" rather than a brand new message.

Check for number of characters

Have not tested, but SmsManager may not take care of texts with 160+ characters.

Figure out how to use the Alarm service to schedule a message to be sent.

Do we need to have a background service running?

Make a list similar to the contacts list for unknown phone numbers.

Do this once the contacts list is finished.

Listview height is weird when a giant contact is added to the list

Remove the settings option from the action bar--remove all menus associated with the action bar.

Doesn't look like we're gonna have any settings to really adjust.

Implement some functionality that checks if our service was killed or something and wakes it back up.

This doesn't have to be implemented yet, but hopefully soon we should have some functionality that protects against phone restarts that kill an alarm that we rely on to schedule a message.

I currently don't even know if this would be a necessary thing, given that Alarm could be protecting against that for us, but just a thought.

On shutdown, cancel all alarms and on bootup reschedule them.

Theoretically on bootup if the app schedules some alarm for before the current time it'll just fire it off immediately.

Add a button to the selected contacts list that removes the contact from the list.

Maybe the whole row can just be a one click remove contact.

Add a splash page.

It could look nice to have a splash page show up for like 2 seconds when the user opens the app.

On smaller devices, the selected contacts list can get big enough so that it pushes the Text field out of view.

Either make the entire activity scrollable (which could actually solve some problems), or make the dynamic list height adjustment more reasonable.