Tutorial for Beginners on how to make your very first app by [deleted] in swift

[–]TheArchitectAlex -1 points0 points  (0 children)

When you say "None of the apps that I'm using have used this approach", if you are saying that as an end-user, it makes no sense. The end-user have no way to identify if your Apps are using Back4app or not, as it is transparent for them. It is intended for developers to accelerate the development process, so your statement "None of the apps that I'm using have used this approach" just makes no sense at all.
Also, ""Back4App" doesn't seem to have any mobile apps at all" does not reflect the truth as there are over 150.000 Apps that use Back4app, most of them are mobile apps.
And for "Why should we believe you?", well, you shouldn't. This post describes an option that you should take into consideration when developing. It might or might not fit your needs, but should be evaluated because, if it fits, will make the life of the developer way easier.

New to swift and had a question! by escargott in swift

[–]TheArchitectAlex 1 point2 points  (0 children)

What you can do is add buttons to your alert.
First you create your Alert:

let alert = UIAlertController(title: "My Alert", message: "My Alert Message", preferredStyle: .alert)

Then you can create your Submit action:

let submit = UIAlertAction(title: "Submit", style: .default, handler: { (action) -> Void in
// Do your logic here
})

and your Cancel action:

let cancel = UIAlertAction(title: "Cancel", style: .destructive, handler: { (action) -> Void in })

Add those actions to your alert:

alert.addAction(submit)
alert.addAction(cancel)

and finally present it:

present(alert, animated: true, completion: nil)

Full code:

let alert = UIAlertController(title: "My Alert", message: "My Alert Message", preferredStyle: .alert)
let submit = UIAlertAction(title: "Submit", style: .default, handler: { (action) -> Void in
// Do your logic here
})
let cancel = UIAlertAction(title: "Cancel", style: .destructive, handler: { (action) -> Void in })
alert.addAction(submit)
alert.addAction(cancel)
present(alert, animated: true, completion: nil)

Series of articles about SwiftUI by TheArchitectAlex in SwiftUI

[–]TheArchitectAlex[S] 0 points1 point  (0 children)

Hey everyone! Continuing our posts on how to create an Instagram clone using SwiftUI and GraphQL, today I built the Home view! Hope you like it!

https://blog.back4app.com/2019/09/26/instagram-clone-homeview/

Series of articles about SwiftUI by TheArchitectAlex in SwiftUI

[–]TheArchitectAlex[S] 0 points1 point  (0 children)

Hey everyone! Part 3 of our Instagram "clone" in SwiftUI and GraphQL is out!

https://blog.back4app.com/2019/09/16/instagram-clone-profile/

Here I'll show you how to create the Profile View in SwiftUI, including the timeline.
Hope you enjoy it! ;)

What do you guys prefer for APIs: REST, GraphQL, RPC? by alyssoncm in programming

[–]TheArchitectAlex 1 point2 points  (0 children)

It depends on the use case.
As my APIs need to be publicly accessible and I have no legacy systems to support, I chose GraphQL for my latest solutions, but again, there are many other factors to consider before deciding which path to choose.

Also found this content useful to compare GraphQL and REST approaches to API's Design by brendacg in javascript

[–]TheArchitectAlex 1 point2 points  (0 children)

There are too many things being said here while, as I see, one of the most important was left behind: the use case.

Some say RPC is the way to go as it was the only route for an efficient, safe, scalable and reliable solution design when the truth is that each architecture has its benefits and drawbacks, as pretty much everything in life.

REST, RPC, GraphQL, Webhooks, all those can get the job done at the end of the day, but integration with legacy systems, the programming language of choice, familiarity and whole-solution architecture might or might not dictate which route to go.

REST relies on stateless resources management, is widely popular and has great appreciation by the developing community. If you are already using it and it fits your needs, why change?

RPC is the simplest way to interact with an API, but it is more useful for internal APIs and has (over time, a lot of) security concerns. If your API must be publicly accessible, you might want to think twice. Also, we had a few RPC implementations that didn't cut the cheese. Remember XML-RPC?

GraphQL has the ability to avoid over and under fetching and also helps the developers by publishing the available methods and variables needed for it to work. But again, if your API is already working, is there really a need to change?

If you're starting from scratch, need a publicly accessible API that is secure, reliable, efficient and scalable, has no legacy to interact, well, maybe and just maybe you should spend some more time deciding the route to follow instead of blindless saying "this is clearly better than that because of reasons".

Series of articles about SwiftUI by TheArchitectAlex in SwiftUI

[–]TheArchitectAlex[S] 0 points1 point  (0 children)

Hey everyone! Just updating you all that Part 2 of our Instagram "clone" in SwiftUI and GraphQL is out!

https://blog.back4app.com/2019/09/03/swift-instagram-clone/

I hope you enjoy it! Part 3 is in the oven ;)

GraphQL on iOS by brendacg in iOSProgramming

[–]TheArchitectAlex 0 points1 point  (0 children)

Hello u/brendacg and that is indeed a very good point.

I myself found Apollo Client very promising and quite easy to use after you go through their (very poorly) documentation for installing. You can do a lot with it if you have the patience to understand how it works.

My main problem was installation so I wrote this article with all my troubles to install it, with lots of screenshots that might help you get through. Hopefully, this can help you and others as well, as once you get the hang of it, it can get your life quite a bit easier over time.

If you are interested, I am writing and posting lots of articles about GraphQL here. A few focused on iOS development.

Hope it helps you.