Cn1 offers a push seamless integration using its own servers that takes care of forwarding to fcm/apple servers for you. This works great, but requires a PRO subscription ($79/month)
I love cn1 and want to support the project as much as I can. I want to include push in my app dev, don't mind going through the extra pain of going native and don't find that adding push in my app dev is worth $79/month
I know that part of that cost surely must go towards maintaining the push servers, so I won't ask for something like bringing cn1 push to basic subscriptions which would be unfair
My point is, can native push be done in cn1. Thanks
It isn't actively blocked it's just unsupported due to the complexity in unifying the vastly different behaviors between iOS and Android. E.g. the parse cn1lib supports its own push which isn't based on our implementation.
I can't tell you how well that works.
It's not something we officially support but it's not something we prohibit.
Related
I am using expo 39 SDK is it possible to integrate clever tap notif without ejecting it
In theory, you should be able to do this... However in reality, it may be a bit more complicated. Clovertap is quite specific in terms of exact compatibility without ejecting. It seems that there is little documentation out (at the time of this initial post) for compatibility and use cases between the two systems.
Depending on your underlying problem, another solution may actually be to switch over to FirebaseCloudMessaging.
With that said, lets address the asked problem.
You will probably need to dive into the documentation and attempt code to find out the nitty gritty. I would recommend starting with the push notification documentation:
https://docs.expo.io/push-notifications/overview/
https://docs.clevertap.com/docs/push
I am looking for the list of blockchain projects which are implemented in mobile apps natively. If you can find some, please point me to the list. If not, please let me know why there are no much blockchain projects implemented in mobile natively. Could it be due to performance, gas cost, complexity etc?
There are many risks that you as mobile app developer need to take care of when you ship your DApp in a form of mobile application.
1: Security - building your own app for blockchain means you have to built key management by yourself.
In current state of DApp, we have MetaMask, Cipher browser, Status browser, Trust browser and many others. The main problem that they're trying to solve is account management, the private key management, recovery process & good UX.
All of these need to be taken care of by yourself if you want allow your users to sign up for an account aka creating private key and store it securely in the phone. If hackers managed to reverse engineer and exploit your mobile app, they will be able to crack down the private key vault (the place where you store the private keys for your customers in their phones). You are screwed.
MetaMask and the gang above have experts that know what they are doing and always put security as their main pillar in the engineering process. Apart from that, they also have design team that always come out with better UX ideas so that everyone can adopt blockchain easily.
Bottom line, if you have security and design experties in your team that know well how to handle the key management, recovery process (mnemonic/seed phrases) & etc, it's probably a good idea to build your own inside your mobile app. Otherwise, I strongly recommend you just build web DApps and leverage MetaMask or DApp browsers above.
2: Trust - the idea of blockchain itself it to make everything decentralize and transparent. When you build a mobile app for your DApp, means you making it centralize. Your solution lives somewhere, in a server.
You will be relying on Apple and Google everytime you want to push app updates. Imagine you are an iOS developer and Apple is taking very long time to review and approve your app update submission? There's nothing much you can do because you are in centralized/close loop environment.
If you make it as web based DApp, you can deploy your DApp updates at any time you want. In addition to that, you also can host it to IPFS or Swarm to make it really decentralized application.
The beauty of not making it as a mobile app here is, your users can browse the code because all they have in their browser are static files; HTML, CSS and JS. Your users can tell if you are doing something bad in your code. Because they can right click on your web DApp and see the page source.
But if you are doing this as mobile app, your users can't really know what is 'behind' the app and you will find hard times to convince them later that they are in a good company.
3: Development - Web3JS is the most popular and stable project right now. It acts like a bridge layer between your DApp UI and the blockchain. And of course, it's written and needs to be implemented in JS.
Even now we started to see Web3 has been ported out to many other flavors i.e. for Swift and Kotlin, they are still new. Means, you will spend a lot of man hours later trying to debug and solve issues that only less people know to help/fix it.
To share my experience, I'm a Rubyist and there are some Web3 flavors for Ruby now. But, from what I've tested, they are still far from perfect and stable and at last, I decided to port everything to Web3JS for front-end components and Go for back-end. components.
FYI, the Ethereum Geth client is written in Go, check-out go-ethereum project. That means, everything that you need to do later i.e. creating transaction, signing transaction, querying blocks/transactions, creating/retrieving private key & etc has been tested and being used in real production. At any time when you are stuck, you can go ahead, read the source code of go-ethereum to learn how they do specific thing (the list above).
I'm not going againts all these new flavors. What I'm trying to tell you here is, it's going to take time for all this new flavors to get matured and stable enough. My advice for you now, if you want to do DApp, use Web3JS. If you need some back-end work (your centralized server <> blockchain), use Go.
I hope this helps!
I'm working on an app written in Codename One together with the parse4cn1 library, the combination of which is a real pleasure to use. However, I need support for a few things in parse4cn1 that are not implemented, most importantly ACL and was wondering if Chidiebere has any hints on how to do this (e.g. how did you implement parse4cn1 yourself - from scratch or copying the open source Parse SDK for Android)? If I manage to do something of a decent quality I will try to share back. Thanks in advance
I never got around implementing ACLs (it's still on the TODO list). parse4cn1's interface closes resembles the Parse Android SDK interface and I'll like it to stay that way for convenience. In this case, the interface of interest would be the ParseACL which is documented here.
The actual implementation will need to be done via REST API calls.
Things to bear in mind:
We use the Android SDK API simply for defining methods and signatures for the corresponding class in ParseACL but do not use the SDKs for anything can be be done via REST.
By design, any calls requiring the master key will not be supported in parse4cn1 due to security considerations. If really needed, the functionality should be exposed via server-side cloud code.
Pull requests without unit tests for the added functionality or breaking existing tests will be rejected.
See also the Contributions section of the parse4cn1 github repo.
Good luck with your implementation and I hope to see a PR from you soon ;)
It was implemented from a Java port on top of the REST API's here but was later modified to use the SDK's to allow things like push (which are now no longer relevant).
In the past I just contributed pull a request to the project to get the fixes/features I needed. It was really easy to work with and compile.
I am using this link to build a simple chat application using GCM, and I found this great feature "Google Cloud Endpoints" which makes things easier. But I am afraid to depend on it as I noticed it is still experimental. Can I trust it or should I use Java Servlets instead?
It is true that the tag 'experimental' is a bit scary. If you are concerned, you could consider holding back a bit until Google IO 2013, which is the middle of May. They often make announcement and introduce new technologies there.
They first announced endpoints at last years' Google IO (in July) and if there any significant changes pending for endoints they would likely announce them at this years'.
If you do start using Endpoints, just for Android, and w/o user authentication, I don't think it would be too hard to revert to using a Servlet instead, if you had to (i.e. due to a change in terms that was off-putting). The user authentication stuff would be harder to replace IMO.
As far as I have used Google Cloud Endpoints they work perfectly. Furthermore many interesting features are already implemented, such as integration with Google Eclipse Plugin and testing through the Google APIs Explorer, even in localhost, using the Development Server.
I understand they're still experimental maybe because they're just a new technology not really thoroughly tested yet and are subject to updates. Anyway I've not found significant bugs so far and you should be able to reuse your endpoints with the sucesive versions that will exist. It doesn't seem to be something that will dissapear in the near future...
This is an older question, but for further references I want to say that my short experience was not so pleasant.
I tried "Mobile Backend App". In the beginning, everything worked fine, but after a few days (without changing anything) I received:
GoogleJsonResponseException 404 Not Found
I sow other posts on stackoverflow and manage to solve it by creating another project. I changed the code and it still worked. But again I had problems I played a bit with the 2 projects, I redeployed and changed the settings (tips found on other posts) and it worked. Now it is no longer working, no matter what I do.
I hope that the problem is specific to this project, but nevertheless it is frustrating.
Is there a good solution for A|B Testing in mobile apps like online? I know with iOS it's against the TOS to have different user experiences with identical actions, but what about Android? And what about firms like Apsalar which claim to offer A|B Testing in their analytics for apps? How would one implement that?
Artisan mobile makes an A/B testing solution for iOS and Android.
The basic idea is that you drop the SDK in your app and then put it out in the app store. You can use the service to create A/B tests and optimize your application without having to touch the code or go back through the app store for each test.
For mobile apps, A/B testing basically works by replacing static, hard-coded objects with dynamic objects that can be controlled from a remote server.
This methodology raises a potential performance issue: What if the end user's device is not connected to pull configuration data for an object being tested? We've built Splitforce (http://splitforce.com) to seamlessly setup and manage A/B testing in mobile apps while controlling for performance risk.
Los details
Once the SDK and experiment has been integrated, non-technical product or marketing folks can setup new tests or tweak existing tests on-the-fly - without having to resubmit to the app stores or hassle engineers.
On first app launch, the mobile app requests configuration data from the server and then caches that data locally on the device. This is to both ensure a consistent user experience on subsequent app launches, and prevent corrupt test results by guaranteeing accurate attribution of conversion events to variations.
If the end user's connection fails or is timed-out on first app launch, the library displays a hard-coded 'default' variation. And to make sure that everything is looking good before you go live, we've built a 'shake to preview' functionality in debug mode that does just that :-)
Once the app is deployed with Splitforce event data are stored locally and sent back to the website to be displayed for each variation alongside measurements of observed improvement and statistical confidence.
Instructions on integration of the SDKs and new tests can be found at https://splitforce.com/documentation.
And how is it used?
We've seen Splitforce used to A/B test:
UI elements + layouts (color, text, images, ad/menu placements)
UX workflows
Game dynamics + rules
Prices + promotions
We've also seen the tool used to control mobile apps remotely, by essentially setting one variation of a test subject to 100%.
Yes there is: E.g. the company Leanplum offers a Visual Interface Editor for iOS and Android: This requires no coding, and Leanplum will automatically detect the elements and allow you to change them. No engineers or app store resubmissions required.
Apple must have updated their TOS (https://developer.apple.com/app-store/review/guidelines/#user-interface) - At least I am not aware of anything that prohibits altering the UI in a way that the Leanplum Visual Editor is doing it.
Generally that is achieved by method swizzling (iOS) and reflection (Android).
To learn more about the Leanplum Visual Interface Editor, check out leanplum.com. They offer a free 30-day trial.
(Disclaimer: I am an Engineer at Leanplum.)
I wrote a small open source project called Switchboard.
It let's you A/B test, remote configure and stage rollout things in your native mobile app. It contains a server component that specifies what information the application should have and 2 native clients for android and iOS.
You can find the codebase at github.com/keepsafe/switchboard and a blog post about how you can use it HERE
The new kid around the block is Arise.io. They provide an A/B testing service for iOS and Android.
I wrote MSActiveConfig, an extremely flexible framework to do remote configuration + A/B testing on iOS, with a portable format to be able to implement clients on other platforms: https://github.com/mindsnacks/MSActiveConfig.
This framework is being used in applications with more than 5 million users.
There have been a spate of new entrants in this field...you could check out Swerve, Appiterate, leanplum...all of them seem to be having SDKs for iOS as well, not really sure whether and how Apple TOS allows for that, but since there are some many of them doing it, there must be a way.
Yes, new entrants are showing up in app A/B testing practically every week! But, I think Appiterate has gone two steps ahead of other competitors by creating a visual interface, without any need to re-write code. I have seen their platform (you can ask for an invite. I got a demo within 12 hours) and believe me, it is actual WYSIWYG that they are providing.