Does my app need an export compliance if it uses parse (now migrated to heroku + mongoDB)? I researched a bit and know that export compliance is not needed for parse. Just want to make sure, thanks!
Do you use HTTPS:? I hope you've set up your Parse server to use https/TLS v1.2. Apple's ATS requires TLS v1.2+ these days. You should check with your attorney. I believe you need an export license. Apparently, once your company receives a commodity license, you do not need to reapply. But only your attorney can answer that authoritatively.
Related
I'm trying to get review apps up and running on Heroku. In my usecase I have a bunch of custom domains and I have postdeploy and pr-predestroy scripts that correctly setup all of that. However ACM is not getting enabled for the new apps, so none of the URL's gets certs until someone goes and manually enables ACM. Is there a way to have ACM automatically enabled for new review apps? If it matters any we are manually triggering the creation of the review apps.
The best answer I found was to use the platform API to enable ACM from the postdeploy script https://devcenter.heroku.com/articles/platform-api-reference#app-enable-acm
I have an app which uses Parse and I want to migrate it to Firebase. I was extended the parse installation objects to send customized push notifications. I'm wondering if I can migrate these parse installation objects to Firebase and use it from Firebase.
There is no cookie cutter click-though way to import an app that uses Parse.com into Firebase. The products are too different for that.
There are however migration guides for developers looking to migrate their iOS and Android apps on the Firebase site: https://firebase.google.com/support/guides/#migrating_from_parse
There is also a repo with parse-migration-tools from Firebase: https://github.com/firebase/parse-migration-tools
Finally have a look at this question, where experienced developers chimed in already: How to migrate data from Parse.com to Firebase
[Disclaimer: Former lead of Parse Push. Author of parse-migration-tools]
I'm a bit nervous that you're out of luck if you're referring to "installation Ids". Firebase supports iOS and Android. Android devices aren't going to be easy to port for a few reasons, though iOS can be done without too much work. Let's break it down by the push backend:
Most people who talk about "installation Ids" are talking about Parse's self-hosted push network (PPNS or Parse Push Notification Service). This is hosted at push.parse.com and will go away in January. There's nothing anyone can do to keep those devices connected. As an FYI you'll also realy want to update your apps to disable PPNS because it will likely drain your customers' battery when they have a background service repeatedly trying to connect to a URI that isn't going to exist anymore.
If you're using GCM directly, you're still out of luck actually. Parse uses a version of GCM that's too old to work with Firebase. I tried to help fix it, but we weren't able to upgrade to GCM v4 and keep the Parse design style. The new Firebase SDK makes it possible to fix the issue and keep the Parse design requirements, but I'm far too overextended to build this right now. If someone wants to grab a shovel, I'd be glad to explain the right design.
iOS will actually work. I intended to make this turnkey in parse-migration-tools but won't have time until the end of the year. Firebase Cloud Messaging has a batchImport API for importing iOS tokens. I also wrote support for batchImport in parse-migration-tools to help you import your devices (and other data) faster. If I were migrating Parse Push from iOS, I would personally write a migration and bulkImport function that used batchImport to create GCM tokens and subscribed Parse Channels as FCM topics (note the batchAdd method; it may help you more efficiently do your initial import).
This should do the trick:
https://firebase.google.com/docs/cloud-messaging/ios/client#import_existing_user_apns_tokens
You can just importat all of the existing users device id's and FireBase will generate unique id's for them.
Since CodenameOne doesn't support "the cloud storage API" any more and the parse.com is going to retire soon as well. Does CodenameOne has any plan to release a new Cloud Storage API or provide suggestions/guidelines to help developers to deal with the parse4cn1 library code, cloud code, database structure and data in parse.com?
That is something you will have to figure out yourself as parse4cn1 was initially contributed by a community member and wasn't developed by Codenameone team.
You can use a simple webservices created in php, python or java, hosted along your content with any ISP.
You may also have a look at amazon aws which is promising, they provide a cloud solution but their SDKs is not yet integrated to Codenameone.
I made the parse4cn1 lib and I'm also wondering what's smartest to do. With the announcement of Parse.com's imminent shutdown, there's been a lot of discussion around alternatives. My feeling is that "the dust is yet to settle" as per what options are best and reliable for the longer term (it would be a pity to migrate to another service only for it to be shut down soon). So I personally plan to wait till sometime in Q2 to do a proper evaluation of the alternatives. Hopefully, there'll be more clarity then.
The option to host one's own Parse server (e.g. on AWS or Heroku) is getting interesting. They recently announced support for push notifications on iOS and Android. If (when?) they open source the Parse.com dashboard code, I think that option would be much more interesting.
At some point in the coming months, I plan to make a parse4cn1 release that exposes an option to set the server path. With that, anyone migrating to the Parse server option should, in principle, be able to continue to use the cn1lib. Of course, for features that are supported by the open source Parse server.
PS: Here are pointers to some of such discussions on Parse alternatives:
https://github.com/relatedcode/ParseAlternatives
http://www.slant.co/topics/5219/compare/~firebase_vs_kumulos_vs_kinvey
We run SAP ECC 6.0 basis version 702, and are integrating with Magento for order management. I know that SBOeConnect :eCommerce Integrated with SAP Business One ERP extension exists, but I do not know if this works with our SAP installation.
(SAP ECC 6 and Business One are two very different beasts.)
Has anyone experience with integration the two systems?
Does the extention support SAP ECC 6?
As far as I know that is the only extension. I would recommend contacting them to ask if it supports your version of SAP.
The other option would be to build a custom module. Using the APIs and a cron job you can setup automatic push/pull events to sync data or tie it to an event observer for an action like a new transaction. There are obviously a lot of variables depending on what you specifically want to do.
I am investigating developing an app for Windows Phone 7 that requires access to email/calendar information from Exchange Server (read only).
The way I see it there are 2 options EWS or ActiveSync.
WP7 only supports Basic Authentication.
By default on Exchange server installations the EWS virtual directory has Basic Authentication disabled meaning a configuration change of Exchange Server to allow EWS to be used.
The ActiveSync protocol looks like it would take some time to get your head around and develop an implementation.
The questions are
1. How common is it for people to enable basic authentication for EWS? Is this something that most businesses are likely to not want to do?
How difficult is it to learn and use the ActiveSync protocol? Is it something that could be done in days, weeks or months?
1) To find out about the common configuration of EWS servers I'd spek to some sysadmins and ask them. Maybe try on https://serverfault.com/
1) How difficult something is to learn very much depends on the skills and experience of the person learning and the teaching resources available. This is a non-trivial protocol so I wouldn't expect learning it to take days. There will also be a licensing cost of implementing Excahange ActiveSync which I suspect would make it an expensive option.
Option 3: Create your own web service that acts as a proxy to EWS and does the authentication for you. Ugly and a bit painful, but if your app is architected well, once WP7 supports better authentication, switching to directly hit EWS should be pretty simple.
ActiveSync is painful and does not support everything that EWS supports. I would recommend going the EWS route if you have that option.
If your going to use ActiveSync, think again... it uses wbxml and you would need to create your own API for doing calls - this means crating tokenized blobs which must be 100% perfect and account for all aspects of whatever type of messaging items you are going against or will risk creating bad items or even poison ones. The devistation caused by bad EAS calls could well exceed your customer base... so, you need to be very careful. Also, while the specs are public, it needs an very expensive license. If you license, you would need to get a support contract with a specific schedule in order to get develper support. With a team of developers, it will likely take 3-5 or so years to do a full implementation client side and work out most of the bugs. So, as far as the skills in email development, you and your other developers would need to be pretty hard-core. There may be third party APIs which wrap EAS calls... however, you should be sure that they are licensed and that that the license would cover your development - so, you would need to research those on your own.
EWS has more features and is far, far easier to use and is what is suggested... further, there is no special licensing, etc.
Using a proxy web service+Exchange Managed APIs so that WP7 can go against Exchange without writting a ton of code:
http://www.telerik.com/products/windows-phone/getting-started/exchange-client.aspx
... can also use this approach to use NTLM.
Before considering EAS...
http://blogs.msdn.com/b/webdav_101/archive/2011/09/29/new-to-exchange-activesync-development.aspx