#Kotlin is.... so bad....

[moose-mousse]

So I made an app for PROTO. Written in Kotlin and runs on Android.

Next, I want to upgrade it with a controller mode. It should work so so I simply plug a wired xbox controller into my phone with a USB OTG adaptor… and bam, the phone does all the complex wireless communication and is a battery. Meaning that besides the controller, you only need the app and… any phone. Which anyone is rather likely to have Done.

Now THAT is convenient!

( Warning, the rest of the post turned into... a few rants. ) Why Android? Well I dislike Android less than IOS

So it is it better to be crawling in front of the alter of "We are making the apocalypse happen" Google than "5 Chinese child workers died while you read this" Apple?

Not much…

I really should which over to a better open source Linux distribution… But I do not have the willpower to research which one... So on Android I stay.

Kotlin is meant to be "Java, but better/more modern/More functional programming style" (Everyone realized a few years back that the 100% Object oriented programming paradigme is stupid as hell. And we already knew that about the functional programming paradigme. The best is a mix of everything, each used when it is the best option.) And for the most part, it succeeds. Java/Kotlin compiles its code down to "bytecode", which is essentially assembler but for the Java virtual machine. The virtual machine then runs the program. Like how javascript have the browser run it instead of compiling it to the specific machine your want it to run on… It makes them easy to port…

Except in the case of Kotlin on Android... there is not a snowflakes chance in hell that you can take your entire codebase and just run it on another linux distribution, Windows or IOS…

So... you do it for the performance right? The upside of compiling directly to the machine is that it does not waste power on middle management layers… This is why C and C++ are so fast!

Except… Android is… Clunky… It relies on design ideas that require EVERY SINGLE PROGRAM AND APP ON YOUR PHONE to behave nicely (Lots of "This system only works if every single app uses it sparingly and do not screw each-other over" paradigms .). And many distributions from Motorola like mine for example comes with software YOUR ARE NOT ALLOWED TO UNINSTALL... meaning that software on your phone is ALWAYS behaving badly. Because not a single person actually owns an Android phone. You own a brick of electronics that is worthless without its OS, and google does not sell that to you or even gift it to you. You are renting it for free, forever. Same with Motorola which added a few extra modifications onto Googles Android and then gave it to me.

That way, google does not have to give any rights to its costumers. So I cannot completely control what my phone does. Because it is not my phone. It is Googles phone.

That I am allowed to use. By the good graces of our corporate god emperors

"Moose stares blankly into space trying to stop being permanently angry at hoe everyone is choosing to run the world"

… Ok that turned dark… Anywho. TLDR There is a better option for 95% of apps (Which is "A GUI that interfaces with a database") "Just write a single HTML document with internal CSS and Javascript" Usually simpler, MUCH easier and smaller… And now your app works on any computer with a browser. Meaning all of them…

I made a GUI for my parents recently that works exactly like that. Soo this post:

It was frankly a mistake of me to learn Kotlin… Even more so since It is a… awful language… Clearly good ideas then ruined by marketing department people yelling "SUPPORT EVERYTHING! AND USE ALL THE BUZZWORD TECHNOLOGY! Like… If your language FORCES you to use exceptions for normal runtime behavior "Stares at CancellationException"... dear god that is horrible...

Made EVEN WORSE by being a really complicated way to re-invent the GOTO expression… You know... The thing every programmer is taught will eat your feet if you ever think about using it because it is SO dangerous, and SO bad form to use it? Yeah. It is that, hidden is a COMPLEATLY WRONG WAY to use exceptions…

goodie… I swear to Christ, every page or two of my Kotlin notes have me ranting how I learned how something works, and that it is terrible... Blaaa. But anyway now that I know it, I try to keep it fresh in my mind and use it from time to time. Might as well. It IS possible to run certain things more effective than a web page, and you can work much more directly with the file system. It is... hard-ish to get a webpage to "load" a file automatically... But believe me, it is good that this is the case.

Anywho. How does the app work and what is the next version going to do?

PROTO is meant to be a platform I test OTHER systems on, so he is optimized for simplicity. So how you control him is sending a HTTP 1.1 message of type Text/Plain… (This is a VERY fancy sounding way of saying "A string" in network speak). The string is 6 comma separated numbers. Linear movement XYZ and angular movement XYZ.

The app is simply 5 buttons that each sends a HTTP PUT request with fixed values. Specifically 0.5/-0.5 meter/second linear (Drive back or forward) 0.2/-0.2 radians/second angular (Turn right or turn left) Or all 0 for stop

(Yes, I just formatted normal text as code to make it more readable... I think I might be more infected by programming so much than I thought...)

Aaaaaanywho. That must be enough ranting. Time to make the app

[ectomoog]

The Ecto Moog Vanilla Experience

Updated for 1.20.4

I’m the unwilling user of a MacBook Air, and I’m also someone with strong (picky) preferences for ✨vibes✨, and so to play Minecraft casually on my laptop, I’ve had to jump through several hoops to achieve what I would consider a good vanilla experience.

At this point though, I’ve put probably too much time and effort into it, and so I thought to justify that I’d make a beginner's guide to all the mods, resource packs and game options I use, as of February 2024 (1.20.4). 👇

I will attach a hyperlink to any resources I mention :)

Mods

Ok so to start off, yes, I technically I don't actually play true vanilla Minecraft, but the mods I have installed are all client-side, and for the purpose of improving or optimising the vanilla experience. You can find me and a list of (almost) all these mods on Modrinth.

Fabric & Modrinth (Intro)

To mod the game, I use Fabric. I know that Forge has had some… drama? recently, and I’m gonna be honest I’ve never tried Quilt (I will at some point), but Fabric is super widespread, tons of mods use it so it works just fine for me 😁. When I’m looking for mods, I really prefer to use Modrinth, just because I can follow everything and it’s a really well designed website. (I also tried their launcher but I think it needs a little work?)

As part of Fabric, I do have the Fabric API in my mods folder.

Performance & Optimisation

I use these mods are to make the game run better. Minecraft is notorious for being very poorly optimised, and these mods have been made by a ton of very talented people to fix that.

Sodium

JellySquid’s Sodium is the hot optimisation mod right now for rendering and graphical fixes. It doesn’t have the cosmetic features of Optifine, like dynamic lighting or zoom, but it’s super compatible and gives me great performance. Combined with my other mods, at a 15 chunk render distance in the overworld, I averaged around 50 fps. For a MacBook, that's not bad at all.

To accompany Sodium I've also got Indium, an add-on that provides support for the Fabric Rendering API, which is required for mods that use advanced rendering effects, and Reese's Sodium Options, which adds a better options screen for Sodium’s video settings- it looks better basically.

Lithium

Lithium is a general purpose optimisation mod that improves systems like game physics, mob AI, block ticking, etc without changing vanilla mechanics.

Starlight

Starlight rewrites the entire lighting engine to fix performance and errors. Made for bigger servers, but helpful for client users. I think this is in place of Phosphor.

Dynamic FPS

Dynamic FPS can reduce the game’s FPS when it’s just running in the background- useful for a laptop.

Some more specific optimisation mods:

Entity Culling avoids rendering entities that aren’t directly in your field of view, which is much more thorough than the vanilla approach.

Ferrite Core reduces the memory usage of Minecraft in a ton of different ways.

Immediately Fast optimises how things like entities, particles, text, GUI are rendered, by using “a custom buffer implementation which batches draw calls and uploads data to the GPU in a more efficient way.”

I'm not a programmer so I can’t really explain what Krypton does, something to do with networking stacks, but I know it optimises.. things, lowers server CPU usage and reduces memory usage. I’m barely following along with a lot of these mods.

Fabric Language Kotlin is a dependancy that enables the use of the Kotlin programming language for other Fabric mods. To be honest, I’ve forgotten what mod needs this but I don’t want to delete it, just in case.

Experience

These mods aren’t necessarily about performance, but they do enhance the game in a vanilla kind of way, in my opinion. Some of these could be up for debate but I do think they compliment the base game.

Lamb Dynamic Lights

Lamb Dynamic Lights is a simple but thorough dynamic lighting mod that adds light-emitting handheld items, dropped items and entities.

Zoomify

Zoomify is a super configurable zoom mod. Maybe this is just because of Optifine’s influence, but i think they should add zoom to the base game. At least I feel cool using it 😎

To make Zoomify work, you’ll need, YetAnotherConfigLib, a config library that fills in a couple of holes.

Better F3

Better F3… makes the F3 menu better. There’s the option to customise literally everything, you can colour code, shift and delete parts of the menu depending on your use case, it’s less insane and looks a whole lot better.

MiniHUD

MiniHUD allows you to display customisable F3 lines on the main screen, along with several client-side overlay renderers. I just use it for the mini-F3, and I have my FPS, coords and cardinal direction in the top left corner. It’s honestly more helpful than you’d assume.

MiniHUD requires MaLiLib (masa’s Litemod Library) which is a library mod for mods made by masa and others.

ModMenu

ModMenu adds an in-game menu where you can view the mods you’re running and access their details and setting menus.

Shulker Box Tool Tip

Shulker Box Tool Tip adds a preview of the inside of a Shulker box when it’s in your inventory.

Some more specific experience mods:

Bobby is a rendering mod that allows the player to render more chunks than a server’s fixed distance, by loading in previously generated chunks saved client-side. You can also render them straight from a singleplayer world file. To be honest, I don’t often run into this issue but it’s helpful to have lol.

Cloth Config API adds a config screen for mods in-game.

Iris is a mod that makes shaders super easy, and compatible with Sodium. It's down here because I don’t use shaders often, but it’s essential if you do.

A lot of these mods are subject to change as I find better or updated alternatives, and I'm always on the lookout for more 😁

Resource Packs

For vanilla Minecraft, I actually only use one resource pack, but if you’re familiar with Vanilla Tweaks, you’ll understand why this deserves its own category.

This resource pack allows you to pick which small changes you want to add, and a lot of them are really cool. Some of my favourite tweaks are:

Dark UI

Quieter Nether Portals

Circular Sun and Moon

Numbered Hotbar

Golden Crown

The other tweaks I have are: Classic Minecraft Logo, Lower Warped Nylium, Lower Snow, Lower Crimson Nylium, Lower Podzol, Lower Paths, Lower Grass, Wither Hearts, Ping Color Indicator, Borderless Glass, Lower Fire, Lower Shield, Transparent Pumpkin, Noteblock Banners, Quieter Minecarts, Variated Unpolished Stones, Variated, Terracotta, Variated Stone, Variated Logs, Variated Mushroom Blocks, Variated End Stone, Variated Gravel, Variated Mycelium, Variated Planks, Variated Bricks, Random Moss Rotation, Variated Cobblestone, Variated Grass, Random Coarse Dirt Rotation, Variated Dirt, Darker Dark Oak Leaves, Shorter Tall Grass, Circle Log Tops, Twinkling Stars, Accurate Spyglass, Unique Dyes, Animated Campfire Item, Red Iron Golem Flowers, Brown Leather, Warm Glow, Horizontal Nuggets, Different Stems, Variated Bookshelves, Connected Bookshelves.

Game Options

For the sake of the full experience, here's the important game options:

The End 😇

And that's the whole thing! A lot of this could change at any moment based on my play style, but I think this is a really well rounded experience for vanilla Minecraft. Let me know if there's anything else I should try 😁

[mobileappexpert321]

How can I find the best app development company? Mobile app experts

In today's tech world, a good mobile app is the most important part of everyone. It can change how businesses work and how people connect. But to build your app, you need a reliable app development company. With so many options, how do you pick the best one? Let's look at what to consider, with best advice from MAE.  

1. Establishing Your Project Scope and Requirements:

Before you start looking, you have to figure out what your app needs. What are its main features? Which devices will it work on (iPhone, Android, or both)? How much can you spend, and when do you need it done?

Knowing this helps you explain your ideas clearly and makes sure the development company understands your vision.  

2. Portfolio and Experience: A Window into Expertise:

A top app development company will have a strong portfolio. Check out their past work. Does it match your industry? Do they have apps like yours? Look closely at the design and how easy the apps are to use.

3. Technological Proficiency and Skillset:

The mobile app world is changing very fast. Make sure the company you choosing knows the latest technology. They should know languages like Swift (for iPhones) and Kotlin/Java (for Android), and tools like React Native or Flutter.

Ask about their experience with things like cloud services, databases, and APIs, which are important for your project.

4. Development Process and Communication:

A best app development process is the key to success. Ask the company about their methods (like Agile or Waterfall), how they communicate, and what project tools they use. Regular updates and good communication are super important to keep you in the cycle.

MAE focuses on good communication and teamwork. We work closely with our clients to make sure their ideas become real and that they're always informed.

5. Client Reviews and Testimonials: Measuring Satisfaction:

Reviews and feedback tell you a lot about a company. Look for reviews on sites like Clutch and Google. Pay attention to the good and bad comments, and see how the company handles feedback.

we care about our clients. We support you to read our testimonials and case studies to see what our previous clients have to say.

In Conclusion:

Choosing the good mobile app development company is a big deal. Think about the things we've talked about, and you'll be able to make a best choice. At MAE, we aim to give our clients the best app development services possible. We want to build long-term relationships based on trust, good communication, and a shared goal of success. So constant us today and get your mobile app in the best price.  

[fahrni]

Saturday Morning Coffee

Good morning from Charlottesville, Virginia! ☕️

Life is just flying by. Another week in the books.

I’ll be helping Kim paint the kitchen today. Should be an adventure. 👨‍🎨

Jeffrey Zeldman

Sure, watches that tell you when you’re walking unsteadily and pocket computer phones that show you the closest pizzeria are swell, but were you around for ResEdit?

Unfortunately I wasn’t a Mac user during the ResEdit days but I do know a lot of folks who had fun with it, does that count? 😃

David Ingram • NBC News

Elon Musk’s X is a thriving hub for Nazi support and propaganda, with paid subscribers sharing speeches by Adolf Hitler or content praising his genocidal regime.

Shocked! Surprised! Said no one hearing this. I really don’t know what else to say. He’s a garbage human.

Benjamin Sandofsky

An ex-Apple designer who went on to startup success once told me, “I wish I could give a workshop for Apple jumping into startups, to help them un-learn The Apple Way.” I think Apple makes some of the best products in the world, and I strive to build products with their level of craft and quality, so it pains me to admit that The Apple Way can destroy a lot of startups. Which brings us to Humane.

I have yet to read anything positive about the Humane Pin. It’s not such a bad idea to be able to talk to a device you’re wearing. I’ve had an Apple Watch for years and years, that’s the device to talk to. Siri could use some work but I have a feeling that’s already happening.

John S. Tobey • Forbes

Sell Trump Media Stock (DJT) Now - An Implosion Is Likely

I feel bad for all the folks who believe so much in Trump that they invested their entire life savings in a company poised to fail. There’s a sucker born every day and if Trump is good at anything it’s grifting.

Jimmy Cook

A React Native app is made up of two sides, the JavaScript side and the native side. The native side could be Objective-C/Swift for iOS or Java/Kotlin for Android (not to mention the other platforms for React Native like web and desktop). The React Native Bridge allows the native code and the javascript code to talk to each other. Without the bridge, there is no way for the native code to send any information to the JavaScript code and vise versa.

I’ve been working on a React Native project that integrates into an existing iOS and Android app. We’ve created ways for our React Native developers to use the native iOS and Android code to do work for them and allow them to navigate between React Native views and Native views. There’s definitely more work we could do to improve on what we’ve started but it’s in a decent position.

We’ve already released some React Native based work and will be rolling out more soon.

I’m having a blast!

Devin Meenan • /Film

Jaws' Most Famous Improvised Line Was A Not-So-Sneaky Dig At Studio Producers

This is a fun little read. Make sure you take the time to visit. It’ll only take a minute of your life.

Ellis Karran,Richard Madden • BBC

When they removed the wooden panel, it revealed a large slab of stone featuring a carving of the Lincoln Imp.

How cool is that!

I hope they find more interesting relics around their home. Let’s hope they’re not cursed. 😆

Alexandra Sternlicht • Fortune via News+

But with the House voting in March to force ByteDance to sell its stake in TikTok, 11 former employees interviewed by Fortune tell a vastly different story. Many of those ex-workers, four of whom were employed as recently as last year, say at least some of TikTok’s operations were intertwined with its parent during their tenures, and that the company’s independence from China was largely cosmetic.

This gets more and more interesting by the day. I was against forcing them to sell and I still think it’s a bit heavy handed.

Is there a way to regulate them to make sure American citizens data remains on servers here in the States?

We know Apple had to hand over the keys to iCloud in China. Could that be done here?

It’s above my pay grade and I’m sure someone much smarter than me could give me the lowdown. In the meantime I’ll keep watching from the cheap seats. 🍿

Haela Huntress • Metal Sucks

Maynard James Keenan may be a 60-year-old man ranting against cell phones, but he actually might have a point on this one, at least somewhat.

I like that he does this. When I went to Aftershock in 2019, and Tool closed out the festival, there didn’t seem to be any rules around cell phones. As soon as their set opened it was cell phones up from front to back. I was so tempted to take one away from the dude in front of me blocking my view. Yeah, I was pissed off but managed to keep my cool. It sucked looking around that thing all evening but in the end I got to hear some amazing music.

[sparkouttech]

How to choose the right technology for your App?

Do you need to develop a mobile application? Don't know whether to choose native or hybrid technology? Is the price the only difference or are there more aspects to consider?

It may seem like a simple decision, but it is not exactly like that. The software development services you choose will define many things about your final application, and will have a direct impact on your users' experience. And at this point, you cannot fail.

To be native or to be hybrid: that is the question

There is an ongoing debate surrounding mobile app development. When choosing, this is our first recommendation, always focus on your users and give them the best experience. Nobody has time for bad experiences. The success of your application depends on this.

So, let's talk in detail about native and hybrids . Are you ready?

Advantages and disadvantages of native applications

Native mobile technology refers to the creation of applications suitable to run on specific mobile operating systems. The most common native programming languages ​​are Objective-C or Swift for iOS and Java or Kotlin for Android.

These are the advantages of choosing native technology:

Advantages of native mobile applications

– Greater performance and speed: they are faster than hybrid applications.

– The use of mobile phone hardware is more efficient because it is accessed and used through the device's native functions of the selected operating system.

– Intuitive to use: These apps tend to have a consistent look and feel with most other native apps on the device. Therefore, users find them easier to navigate and use.

– More security: your levels of control and authorization over API calls to and from the server are better.

– Responsive, high-performance applications.

– They can interact with native libraries.

– They work offline: you can use them even if you are not connected (it happens often, believe me).

– Better user experience: due to all the previous advantages and, in addition, because they quickly access and use the integrated capabilities of the user's device such as the calendar, camera or GPS.

– Testing for developers is simpler: you can test more thoroughly.

– They have access to all the advanced functions of native devices.

– Its better distribution in application stores improves its discoverability.

But of course it also has some cons:

Disadvantages of native mobile applications

– Its development is expensive.

– They only work on one platform.

– They require more resources from the developer.

– Less code reuse.

– Its development takes a lot of time.

– Require frequent updates.

– They must be recorded into a different language to port them to a diverse ecosystem of devices.

– Your upfront expenses are more expensive compared to hybrid applications.

– They are not the best option when developing simple applications.

Advantages and disadvantages of hybrid applications

Now it's time to talk about hybrid technology.  Mix of native apps and web apps is hybrid app. Therefore, many mistakenly describe them as websites packaged in a native wrapper.

Languages ​​like JavaScript, HTML5, and CSS are used for hybrid app development and hybrid app framework such as Flutter, React Native, Ionic, Xamarin, or Cordova re used

Let's see them.

Let's start on the positive side and talk about the advantages of this technology.

Advantages of hybrid mobile applications

– Achieve greater developer productivity thanks to cross-platform compatibility.

– They reduce development costs because they are easier to build, require less development time, and only require one code base for multiple platforms.

– They do not need a web browser like web applications.

– They have access to internal APIs and device hardware.

– need a single code base for multiple platforms.

– They reach a broader audience through various platforms.

– Easy to launch and update.

On the other hand, we have the disadvantages:

Cons of Hybrid Mobile Apps

– The user experience is never as good as that of a native app.

– Lower performance.

– Lower speed.

– Less flexibility.

– More user interface design time.

– Limited tools.

– Test complexity: This is because they share a lot of code between platforms and some of that code is often native to take advantage of the underlying hardware.

– They depend on a third-party platform to deploy the application wrapper.

– They are not convenient when more customization is needed. In this case, native apps are more efficient when it comes to reducing costs.

4 tips for selecting the right technology for your application

Product lifespan: If you plan to develop a long-term mobile application (for example, mobile banking), native development frameworks and tools are more stable.

Performance and user experience: This should be one of your top priorities. Regardless of the custom software development services you choose, your users' experience must be excellent because it is the key to the success of an application. According to this, native applications ensure the best user experience, but require more development time. On the contrary, the user experience of hybrid applications is less, but the development time is shorter than that of native ones.

Access to hardware resources: Native technology is the option when the application requires complete access to all the resources and services of the target device. If not, hybrid technology is also a good option.

UI/UX Design: (In general) native apps offer more impressive visuals and exceptional UX, but hybrid apps can also do a good job.

So, the final decision is…

When the moment of truth arrives, you have to decide. Each client has their reasons for choosing one path or another, but their impact on the final product must be clarified.

 We are a custom software development company, obsessed with quality and specialized in mobile apps and unique user experiences. We create world-class digital products for startups and companies, with the aim of transforming their businesses.

[citrusella-flugpucker]

Habitica ideas I had that never saw the light of day

((Because of stuff like what's described in this post, for context as to why I'm not doing it. Was originally going to be a longer post that was sort of a debrief retrospective on my overall feelings on the situation now that it's not heat of the moment with high-running emotions... but I'm just gonna do a bulleted list of tools I never finished that were going to be kinda cool but now no one will be able to use ever

How-bout-it-ca: An idea I never even started coding which would have picked a random task from your tasks and showed it to you. I mostly didn't ever start on this because other tools included part of its envisioned functionality. ...And also at the time I was bad at API. Shhhhhh. (Abandoned: Stopped thinking about it in like 2018 or 2019?)

Pearl Points Steven Universe CSS style: A CSS style that I actually coded a lot of (both pre and post 2017 redesign) but never felt like finishing because I was worried about intellectual property implications (Abandoned: Sometime in like 2020 or so was the last time I touched it)

Image/icon-supported Habitica CSS style: A CSS style I envisioned that would allow interface text to have communication/AAC style icons near it or instead of the text, to make the interface more understandable for users who understand pictures better than text. I got through a proof-of-concept coding session using emoji and didn't follow up with more coding. Idea was to have freely-licensed icon sets built in but also allow an option for users to use their own images. (Abandoned: Sometime in 2022)

"50 Shades of Habitica" CSS style: Jokingly mentioned the title of my draft file to Lemoness and was told I couldn't take that name live even though she thought it was funny. Named that was because it was going to be a CSS style that allowed every color on the entire website to be customized but never really got off the ground because the website was changing enough of the time to make it hard to keep up (this is also why I don't have an alternate name other than the disallowed name of my draft file). (Abandoned: 2017 or 2018)

InnVoices: A script that would have checked if you were in the inn each night and charged you a "fee" to stay there (with optional "stay in but pay all your money" or "get kicked out either with or without casting skills or using healing potions first" options for if you didn't have enough money). Script version was mostly done and I was considering going back to the Tasker version and fixing the issues that had necessitated me learning Google Apps Script JS in the first place when all the Stuff happened. (Abandoned: Stopped coding 2022, removed evidence of existing code logic from internet 2023)

Forbidden Forest for Habitica: An Android app coded in Kotlin that would have allowed users to do some things coded into the API but not coded into the official clients, like assigning task aliases for API use (or things not coded into the official Android client specifically, like rebirth), without having to understand much about how to use the API themselves. Was still hashing out what to include but was about to test out adding a basic API call when the Stuff happened. (Abandoned: 2022)

Might edit to add more if more come to mind (these are the ones that never saw the light of day, not anything I decided to take down in February).

*plays "My Heart Will Go On" or something*

Maybe now I will probably never post about Habitica again on Tumblr. Maybe.))

[mutter-official]

Kotlin isn't quite as bad from what I've heard.

it fixes some of Java's strangeness. for example, it kind of fixes type erasure (though the architecture of the JVM prevents it from completely fixing type erasure, since there are some runtime checks involved)... but the keyword here is some. it's still a JVM-based language, so it still inherits a lot of Java's Problems.

so java's verbosity is bothering me

oh this'll probably become a masterpost for all the stupid java stuff I'm having to do for this class now

[xpc-web-dev]

Updates: I was self-sabotaging and in the end I almost missed two good opportunities.

How are you? I hope well.

I've had more instabilities in the last few days (if you follow me around here, you already know that this seems to be routine HEHUEHEH)

But things are improving and I've set some goals that have helped me feel more confident about where to go next.

Now I wanted to share news, what I learned in this process and what I will share from now on.

The prints above are from processes/scholarships that I was accepted.

The first is the Big data Engineer training proposed by a startup in the state where I live.

The second is training focused on the front-end (from Html to React.js and other soft skills)

The second one I applied for in February and I didn't even expect to be accepted, I took a simple question test and sent it on. This month I received acceptance and I was like "look how cool, I think I can learn well and the bank that sponsors it is famous in my country, so it will be nice to have it on my resume".

This is just a training, no possibility of hiring.

The first is precisely the point of self sabotage that I want to talk about.

Everything involving Data/AI is complex and a hell of a responsibility for me, so it's for everyone, but you have to put in a lot of effort. First I did the test there was SQL (I DIDN'T EVEN KNOW ANYTHING UHEUHEUE, Only with google searches and logic I got it) . And then there were issues with Matrix and Vectors AND I HAVE NEVER BEEN SO GRATEFUL TO NOVEMBER/DECEMBER BEA.

Thanks to all those exercises I managed to do (I just don't know how many I got right and how many I got wrong).

BUT here comes the self-sabotage I applied or signed up for this vacancy more than 3 times (the good and bad thing is that the platform kept the test, so it was only the first one I took) I was ALWAYS like: "I won't make it." "It's going to be too long for me", "I don't even have a background in math (they don't ask for math as a requirement, just a language and sql)", "I won't be approved", " I'm horrible at logic, even if I pass it will go wrong."

And so this week, before they reveal who passed, I wrote to myself again, with the feeling of "Whatever happens and that's it".

The result was yesterday but as nothing appeared in my email I thought,"I didn't pass and it's ok, let's continue with java"

-Yes, I started Java because I signed up for a Kotlin bootcamp sponsored by a good company. The best of this bootcamp could participate in their selection process. They don't pay well, but it would be enough to keep me going, so I just went.-

When I saw the notification in the email today I was in shock for many minutes, before and after HUEUEHUUE. "Did I really pass?"

In this program you can also have access to participate in the company's selection process. But no guarantee 100% work at the end.

I will try to focus more on the issue of doing my best in training and having it on my curriculum. (Strategy to regulate my anxiety). I want to work there, but I don't control the future, so I'll just focus on doing my best.

And this is where I wanted to encourage anyone reading this to try even if they don't think they can.

If I hadn't written myself again for the 4th time this week I wouldn't be in this training that will be good for my CV since I want to go to Artificial Intelligence.

Is afraid? Go scared! You can cross good doors and achieve things you never imagined. So for your future and also past versions, always try to believe or pretend to believe in yourself.I'm still trying, believe me

NOW WHAT WILL I POST?

I will post my routine with each of the classes.

First I'll need to level up my Python and SQL. So even though the big data training starts this week (it will be every day) the first week along with that I'm finishing that python course and practicing SQL.

While Big data will be every day from 19:00 2 hours each class, but I don't know how many classes a day yet. The Front-end are recorded classes and only 1 day a week we have live meetings and I'll probably have to reconcile both, but that's a problem for the future UHEHUEUE.

Maybe I'll separate it into 2 posts so I don't get so confused since they are different things.

I'm excited and wish those of you who are reading and trying to learn code to get good learning opportunities or jobs in the midst of everything that's going on.

Drink water and have a great weekend.

[apkmama]

A Detailed Guide On How To Make An App For Free

If your concept for a mobile app is fantastic, this is the upcoming utility, game, or method of social expression that will go viral. In any case, you think this is fantastic and want to spread the word about it to everyone. If you are wondering where should you start regarding how to make an app for free, read on.

It is crucial to develop your idea first. You can mentally create a rough draught of your application, but have you considered all the minor things that set a great application apart from a mediocre one? It's crucial to take a seat and reflect on the overall mobile app experience for a few minutes.

Everyone believes that their concepts are brilliant, don't they? How can you comprehend that others find the idea for a mobile application you created intriguing regarding how to make an app for free? Turn your inner circle into a cordon sanitaire to evaluate the viability of ideas:

Once you have a concept that works, test it to see if it is as effective as you believe it to be. There are a tonne of excellent applications that perform essentially the same function, but for one reason or another, some stand out and are well-liked while others are not. Your app doesn't need to be ranked first in the store to be well-liked or successful. But he must at least appear normal regarding how to make an app for free.

It might be difficult to learn how to create apps, especially if you have no prior experience. But it's conceivable. Particularly if your concept focuses on the distinctiveness of the features rather than the technologies themselves, like Flappy Bird. The application process is simple. But it was a fascinating and original idea. Check out the Apple Passbook right now.

The concept is really straightforward, but the technology that protect your data, connect to merchants, connect to your fingerprint, and other things like that are fairly complicated. Consider the case when you require cutting-edge technology for an app that utilises a device in a unique way. Then, creating the app from scratch can be challenging.

Now, compared to learning to programme on your own, things will be a little simpler if you choose to pay someone to develop your application. However, the issue of cost naturally emerges here. The benefits of using an office over doing it yourself are numerous. They have knowledge. So they are already aware of all the development's potential hazards. They'll create a quick and optimised application. It won't have a bad design concerning how to make an app for free.

However, you must be certain that the people you hire are qualified. Finding a company that will listen to your story and thoroughly comprehend it prior to beginning the code-writing process is the first and most important step in this process. Many people want to begin creating right away and billing you, but this is not the appropriate approach.

Let's say you don't have any programming experience and are solely driven by a strong want to create. Learning at least one programming language is the first step. Currently, Java or Kotlin can be used to create Android applications if you want to learn how to create apps. However, if you want to work as a professional developer, Kotlin is preferred. Then you must be able to at least "read" Java (and better write in it). It is important regarding how to make an app for free.

These languages have very similar syntax, share the same fundamental ideas, and are quite similar in their operation. We begin with Java at our Android development department and transition to Kotlin in the middle of our studies. The graduate is thus totally ready to pursue a career as an Android developer. You must know this regarding how to make an app for free.

[paolo-redaelli]

Eiffeldoc: ANY

twin: ANY– Return a new object with the dynamic type of Current. copy (other: ANY) — Update current object using fields of object attached to other, so as to yield equal objects. Too bad that those Eiffel features, (function members) available in each and every object and variable are not available in Kotlin.

[itechscripts2]

Can I Learn Kotlin Without Learning Java?

You can learn Kotlin without learning Java. First, we need to know how Kotlin relates to Java. So back in the 90s Java was developed to be a platform-agnostic language, meaning that you could write the code, compile it into one executable, and then run it anywhere. Java accomplished this through Java bytecode. Java bytecode is kind of an intermediary form of code between what we write as developers and what the machine understands. So, the code is compiled into Java bytecode which is executed on the Java virtual machine. The Java virtual machine is something that's installed on computers all across the world. There are three billion devices, famously that run Java, and this is what led to Java's success. Kotlin is interesting because what it does is, it also runs on top of the Java virtual machine. All Kotlin code is compiled into Java bytecode. Kotlin wasn't the first language to do this either. There's also Scala and Groovy, which you might have heard of. But what makes Kotlin so interesting is that the interoperability between Java and Kotlin was one of the main focal points in the design of the language. So, with Kotlin and its seamless interoperability with Java, you can leverage the entire Java ecosystem from all 30 years of its history and leverage that in your applications. That's a great strength of Kotlin, but it's also one of the main reasons why it's important to learn Java before learning Kotlin. Say, for instance, you're working on a program in Kotlin and you're using some Java libraries. If you're going to be writing any Android apps, then you're going to be using some Java libraries. Say, for instance, you find a bug in the code, something is going wrong, and you trace it back to some Java code in the Android library and you want to understand what's going on. If you do not know Java, then this is going to be a problem. So, I would say that learning either Kotlin or Java while ignoring the other is a really bad idea. Java has a huge history and a giant ecosystem, so you're probably going to run into Java code at some point in your developer career. So, what I would recommend is if you don't know Java and are wondering which one to pick to start by learning Kotlin, first become familiar with the language, and then also learn Java as needed. So, whenever you run into an issue where you have to dig around in a Java library, do some Googling. Some research on that and make sure you understand what's going on on the Java side of things. Also, it's really interesting to learn Java after you've learned Kotlin so you can understand some of the design. Kotlin and Java both are designed to compile to bytecode, there are a lot of design decisions that went into the common language that you can see.

[psychicanchortimemachine]

Solving Common Cross-Platform Issues When Working With Flutter

When mistreatment cross-platform frameworks, folks may forget the nuances of every of the platforms they need their code to run on. This text aims to handle that.

Specifically, people sometimes confuse it with the older Web-based mobile (and desktop) cross-platform frameworks, which basically were just Web pages running within browsers running within a wrapper app.

That was truly cross-platform in the sense that the interfaces were the same anyway because you only had access to the interfaces normally accessible on the Web.

Flutter isn’t that, though: it runs natively on each platform, and it means each app runs just like it would run if it were written in Java/Kotlin or Objective-C/Swift on Android and iOS, pretty much. You need to know that because this implies that you need to take care of the many differences between these very diverse platforms.

Example 1: Storage

I recently wrote on my diary concerning the necessity for a special approach to storing JWTs in net apps compared to mobile apps. That is due to the various nature of the platforms’ storage choices, and therefore the got to recognize every and their native development tools.

WEB

When you write a Web app, the storage options you have are:

1. Downloading/uploading files to/from disk, which requires user interaction and is therefore only suitable for files meant to be read or created by the user.

2. Using cookies, which may or may not be accessible from JS (depending on whether or not they’re httpOnly) and are automatically sent along with requests to a given domain and saved when they come as part of a response.

3. Using JS localStorage and sessionStorage, accessible by any JS on the website, but only from JS that is part of the pages of that website.

MOBILE

The situation when it comes to mobile apps is completely different. The storage options are the following:

1. Local app documents or cache storage, accessible by that app.

2. Other local storage paths for user-created/readable files.

3. NSUserDefaults and SharedPreferences respectively on iOS and Android for key-value storage.

4. Keychain on iOS and KeyStore on Android for secure storage of, respectively, any data and cryptographic keys.

If you don’t recognize that, you’re getting to build a multitude of your implementations as a result of you would like to understand what storage answer you’re truly exploitation and what the benefits and downsides area unit.

CROSS-PLATFORM SOLUTIONS: AN INITIAL APPROACH

Using the Flutter shared_preferences package uses localStorage on the Web, SharedPreferences on Android and NSUserDefaults on iOS. Those have utterly completely different implications for your app, particularly if you’re storing sensitive info like session tokens: localStorage are often scan by the shopper, thus it’s a tangle if you’re prone to XSS. although mobile apps aren’t very prone to XSS, SharedPreferences and NSUserDefaults don't seem to be secure storage ways as a result of they will be compromised on the shopper facet since they're not secure storage and not encrypted.  That’s as a result of they're meant for user preferences, as mentioned here within the case of iOS and here within the robot documentation once talking concerning the protection library that is meant to produce wrappers to the SharedPreferences specifically to inscribe the info before storing it.

SECURE STORAGE ON MOBILE

The only secure storage solutions on mobile are Keychain and KeyStore on iOS and Android respectively, whereas there is no secure storage on the Web. The Keychain and KeyStore area unit terribly completely different in nature, though: Keychain could be a generic credentials storage resolution, whereas the KeyStore is employed to store (and will generate) science keys, either stellate keys or public/private keys.

This means that if, for example, you would like to store a session token, on iOS you'll be able to let the OS manage the coding half and simply send your token to the Keychain, whereas on humanoid it’s a small amount a lot of of a manual expertise as a result of you would like to get (not hard-code, that’s bad) a key, use it to cypher the token, store the encrypted token in SharedPreferences and store the key within the KeyStore. There area unit completely different approaches to it, as area unit most things in security, however the only is perhaps to use stellate coding, as there's no want for public key cryptography since your app each encrypts and decrypts the token. Obviously, you don’t have to be compelled to write mobile platform-specific code that will all of that, as  there is a Flutter plugin that does all of that, for instance.

THE LACK OF SECURE STORAGE ON THE WEB

That was, actually, the rationale that compelled ME to put in writing this post. I wrote regarding exploitation that package to store JWT on mobile apps and other people wished the net version of that however, as I said, there's no secure storage on the net. It doesn’t exist. Does that mean your JWT must be get in the open? No, not at all. you'll be able to use httpOnly cookies, can’t you? Those area unitn’t accessible by JS and are sent solely to your server. the problem thereupon is that they’re continuously sent to your server, notwithstanding one amongst your users clicks on a GET request address on somebody else’s web site which GET request has aspect effects you or your user won’t like. This really works for different request varieties moreover, it’s simply a lot of sophisticated. It’s referred to as Cross-Site Request Forgery and you don’t wish that.  It’s among the net security threats mentioned in Mozilla’s MDN docs, wherever you'll be able to notice a a lot of complete rationalization. There area unit interference strategies. the foremost common one has 2 tokens, actually: one amongst them aiming to the shopper as Associate in Nursing httpOnly cookie, the opposite as a part of the response.  The latter must be hold on in localStorage and not in cookies as a result of we have a tendency to don’t wish it to be sent mechanically to the server.

SOLVING BOTH

What if you have both a mobile app and a Web app? That can be dealt with in one of two ways:

1. Use the same backend endpoint, but manually get and send the cookies using the cookie-related HTTP headers;

2. Create a separate non-Web backend endpoint that generates different token than either token used by the Web app and then allow for regular JWT authorization if the client is able to provide the mobile-only token.

Running Different Code On Different Platforms

Now, let’s see how we can run different code on different platforms in order to be able to compensate for the differences.

CREATING A FLUTTER PLUGIN

Especially to unravel the matter of storage, a technique you'll do this is with a plugin package: plugins offer a typical Dart interface and might run totally different code on different platforms, together with native platform-specific Kotlin/Java or Swift/Objective-C code. Developing packages and plugins is quite complicated, however it’s explained in several places on the net et al. (for example in Flutter books), together with the official Flutter documentation. For mobile platforms, for example, there already may be a secure storage plugin, and that’s flutter_secure_storage, that you'll notice associate example of usage here, however that doesn’t work on the net, as an example.

On the opposite hand, for easy key-value storage that additionally works on the net, there’s a cross-platform Google-developed first-party plugin package known as shared_preferences, that incorporates a Web-specific part known as shared_preferences_web that uses NSUserDefaults, SharedPreferences or localStorage reckoning on the platform.

TARGETPLATFORM ON FLUTTER

After importing package:flutter/foundation.dart, you can compare Theme.of(context).platform to the values:

TargetPlatform.android

TargetPlatform.iOS

TargetPlatform.linux

TargetPlatform.windows

TargetPlatform.macOS

TargetPlatform.fuchsia

and write your functions so that, for each platform you want to support, they do the appropriate thing. This will come especially useful for the next example of platform difference, and that is differences in how widgets are displayed on different platforms.

For that use case, in particular, there is also a reasonably popular flutter_platform_widgets plugin, which simplifies the development of platform-aware widgets.

Example 2: Differences In How The Same Widget Is Displayed

You can’t simply write cross-platform code and fake a browser, a phone, a computer, and a smartwatch area unit a similar factor — unless you wish your humanoid and iOS app to be a WebView and your desktop app to be designed with lepton.

There area unit many reasons to not try this, and it’s not the purpose of this piece to convert you to use frameworks like Flutter instead that keep your app native, with all the performance and user expertise blessings that go with it, whereas permitting you to jot down code that's progressing to be a similar for all platforms most of the time.

That requires care and a focus, though, and a minimum of a basic data of the platforms you wish to support, their actual native genus Apis, and every one of that.

React Native users have to be compelled to pay even additional attention thereto as a result of that framework uses the inherent OS widgets, thus you really have to be compelled to pay even additional attention to however the app appearance by testing it extensively on each platforms, while not having the ability to modify between iOS and Material device on the fly like it’s potential with Flutter..

WHAT CHANGES WITHOUT YOUR REQUEST

There are some aspects of the UI of your app that are automatically changed when you switch platforms. This section also mentions what changes between Flutter and React Native in this respect.

Between Android And iOS (Flutter)

Flutter is capable of rendering Material widgets on iOS (and Cupertino (iOS-like) widgets on Android), however what it DOESN’T do is show precisely the same factor on robot and iOS: Material theming particularly adapts to the conventions of every platform.

For instance, navigation animations and transitions and default fonts area unit completely different, however those don’t impact your app that abundant. What might have an effect on a number of your decisions once it involves aesthetics or wife is that the indisputable fact that some static components conjointly modification.

Specifically, some icons modification between the 2 platforms, app bar titles area unit within the middle on iOS and on the left on robot (on the left of the on the market area just in case there's a back button or the button to open a Drawer (explained here within the Material style pointers and conjointly called a hamburger menu). Here’s what a fabric app with a Drawer feels like on Android:

And what the same, very simple, Material app looks like on iOS:

Between Mobile and Web and With Screen Notches (Flutter)

On the online there's a small amount of a unique state of affairs, as mentioned conjointly during this Smashing article regarding Responsive net Development with Flutter: specifically, additionally to having to optimize for larger screens and account for the means folks expect to navigate through your web site — that is that the main focus of that article — you have got to stress regarding the very fact that generally widgets square measure placed outside of the browser window.

Also, some phones have notches within the high a part of their screen or different impediments to the proper viewing of your app attributable to some form of obstruction. Both of those issues may be avoided by wrapping your conveniences during a SafeArea widget, that may be a explicit reasonably cushioning convenience that makes certain your widgets comprise an area wherever they will really be displayed empty preventive the users’ ability to envision them, be it a hardware or code constraint.

IN REACT NATIVE

React Native needs far more attention and a way deeper information of every platform, additionally to requiring you to run the iOS machine furthermore because the mechanical man human at the terribly least so as to be able to check your app on each platforms: it’s not identical and it converts its JavaScript UI parts to platform-specific widgets.

In alternative words, your React Native apps can invariably seem like iOS — with Cupertino UI parts as they're generally known as — and your mechanical man apps can invariably seem like regular Material style mechanical man apps as a result of it’s victimization the platform’s widgets. The distinction here is that Flutter renders its widgets with its own low-level rendering engine, which implies you'll be able to check each app versions on one platform.

Getting Around That Issue

The Other Side: Using The Wrong Widgets For The Right Reasons

But that also means that you can do most of your Flutter development on a Linux or Windows workstation without sacrificing the experience of your iOS users, and then just build the app for the other platform and not have to worry about thoroughly testing it.

Next Steps Cross-platform frameworks are awesome, but they shift responsibility to you, the developer, to understand how each platform works and how to make sure your app adapts and is pleasant to use for your users. Other small things to consider may be, for example, using different descriptions for what might be in essence the same thing if there are different conventions on different platforms.It’s great to not have to build the two (or more) apps separately using different languages, but you still need to keep in mind you are, in essence, building more than one app and that requires thinking about each of the apps you are building.

We will be happy to answer your questions on designing, developing, and deploying comprehensive enterprise web, mobile apps and customized software solutions that best fit your organization needs. As a reputed Software Solutions Developer we have expertise in providing dedicated remote and outsourced technical resources for software services at very nominal cost. Besides experts in full stacks We also build web solutions, mobile apps and work on system integration, performance enhancement, cloud migrations and big data analytics. Don’t hesitate to

get in touch with us!

[lakhwanabhishek]

Solving Common Cross-Platform Issues When Working With Flutter

When mistreatment cross-platform frameworks, folks may forget the nuances of every of the platforms they need their code to run on. This text aims to handle that.

Specifically, people sometimes confuse it with the older Web-based mobile (and desktop) cross-platform frameworks, which basically were just Web pages running within browsers running within a wrapper app.

That was truly cross-platform in the sense that the interfaces were the same anyway because you only had access to the interfaces normally accessible on the Web.

Flutter isn’t that, though: it runs natively on each platform, and it means each app runs just like it would run if it were written in Java/Kotlin or Objective-C/Swift on Android and iOS, pretty much. You need to know that because this implies that you need to take care of the many differences between these very diverse platforms.

Example 1: Storage

I recently wrote on my diary concerning the necessity for a special approach to storing JWTs in net apps compared to mobile apps. That is due to the various nature of the platforms’ storage choices, and therefore the got to recognize every and their native development tools.

WEB

When you write a Web app, the storage options you have are:

1. Downloading/uploading files to/from disk, which requires user interaction and is therefore only suitable for files meant to be read or created by the user.

2. Using cookies, which may or may not be accessible from JS (depending on whether or not they’re httpOnly) and are automatically sent along with requests to a given domain and saved when they come as part of a response.

3. Using JS localStorage and sessionStorage, accessible by any JS on the website, but only from JS that is part of the pages of that website.

MOBILE

The situation when it comes to mobile apps is completely different. The storage options are the following:

1. Local app documents or cache storage, accessible by that app.

2. Other local storage paths for user-created/readable files.

3. NSUserDefaults and SharedPreferences respectively on iOS and Android for key-value storage.

4. Keychain on iOS and KeyStore on Android for secure storage of, respectively, any data and cryptographic keys.

If you don’t recognize that, you’re getting to build a multitude of your implementations as a result of you would like to understand what storage answer you’re truly exploitation and what the benefits and downsides area unit.

CROSS-PLATFORM SOLUTIONS: AN INITIAL APPROACH

Using the Flutter shared_preferences package uses localStorage on the Web, SharedPreferences on Android and NSUserDefaults on iOS. Those have utterly completely different implications for your app, particularly if you’re storing sensitive info like session tokens: localStorage are often scan by the shopper, thus it’s a tangle if you’re prone to XSS. although mobile apps aren’t very prone to XSS, SharedPreferences and NSUserDefaults don't seem to be secure storage ways as a result of they will be compromised on the shopper facet since they're not secure storage and not encrypted.  That’s as a result of they're meant for user preferences, as mentioned here within the case of iOS and here within the robot documentation once talking concerning the protection library that is meant to produce wrappers to the SharedPreferences specifically to inscribe the info before storing it.

SECURE STORAGE ON MOBILE

The only secure storage solutions on mobile are Keychain and KeyStore on iOS and Android respectively, whereas there is no secure storage on the Web. The Keychain and KeyStore area unit terribly completely different in nature, though: Keychain could be a generic credentials storage resolution, whereas the KeyStore is employed to store (and will generate) science keys, either stellate keys or public/private keys.

This means that if, for example, you would like to store a session token, on iOS you'll be able to let the OS manage the coding half and simply send your token to the Keychain, whereas on humanoid it’s a small amount a lot of of a manual expertise as a result of you would like to get (not hard-code, that’s bad) a key, use it to cypher the token, store the encrypted token in SharedPreferences and store the key within the KeyStore. There area unit completely different approaches to it, as area unit most things in security, however the only is perhaps to use stellate coding, as there's no want for public key cryptography since your app each encrypts and decrypts the token. Obviously, you don’t have to be compelled to write mobile platform-specific code that will all of that, as  there is a Flutter plugin that does all of that, for instance.

THE LACK OF SECURE STORAGE ON THE WEB

That was, actually, the rationale that compelled ME to put in writing this post. I wrote regarding exploitation that package to store JWT on mobile apps and other people wished the net version of that however, as I said, there's no secure storage on the net. It doesn’t exist. Does that mean your JWT must be get in the open? No, not at all. you'll be able to use httpOnly cookies, can’t you? Those area unitn’t accessible by JS and are sent solely to your server. the problem thereupon is that they’re continuously sent to your server, notwithstanding one amongst your users clicks on a GET request address on somebody else’s web site which GET request has aspect effects you or your user won’t like. This really works for different request varieties moreover, it’s simply a lot of sophisticated. It’s referred to as Cross-Site Request Forgery and you don’t wish that.  It’s among the net security threats mentioned in Mozilla’s MDN docs, wherever you'll be able to notice a a lot of complete rationalization. There area unit interference strategies. the foremost common one has 2 tokens, actually: one amongst them aiming to the shopper as Associate in Nursing httpOnly cookie, the opposite as a part of the response.  The latter must be hold on in localStorage and not in cookies as a result of we have a tendency to don’t wish it to be sent mechanically to the server.

SOLVING BOTH

What if you have both a mobile app and a Web app? That can be dealt with in one of two ways:

1. Use the same backend endpoint, but manually get and send the cookies using the cookie-related HTTP headers;

2. Create a separate non-Web backend endpoint that generates different token than either token used by the Web app and then allow for regular JWT authorization if the client is able to provide the mobile-only token.

Running Different Code On Different Platforms

Now, let’s see how we can run different code on different platforms in order to be able to compensate for the differences.

CREATING A FLUTTER PLUGIN

Especially to unravel the matter of storage, a technique you'll do this is with a plugin package: plugins offer a typical Dart interface and might run totally different code on different platforms, together with native platform-specific Kotlin/Java or Swift/Objective-C code. Developing packages and plugins is quite complicated, however it’s explained in several places on the net et al. (for example in Flutter books), together with the official Flutter documentation. For mobile platforms, for example, there already may be a secure storage plugin, and that’s flutter_secure_storage, that you'll notice associate example of usage here, however that doesn’t work on the net, as an example.

On the opposite hand, for easy key-value storage that additionally works on the net, there’s a cross-platform Google-developed first-party plugin package known as shared_preferences, that incorporates a Web-specific part known as shared_preferences_web that uses NSUserDefaults, SharedPreferences or localStorage reckoning on the platform.

TARGETPLATFORM ON FLUTTER

After importing package:flutter/foundation.dart, you can compare Theme.of(context).platform to the values:

TargetPlatform.android

TargetPlatform.iOS

TargetPlatform.linux

TargetPlatform.windows

TargetPlatform.macOS

TargetPlatform.fuchsia

and write your functions so that, for each platform you want to support, they do the appropriate thing. This will come especially useful for the next example of platform difference, and that is differences in how widgets are displayed on different platforms.

For that use case, in particular, there is also a reasonably popular flutter_platform_widgets plugin, which simplifies the development of platform-aware widgets.

Example 2: Differences In How The Same Widget Is Displayed

You can’t simply write cross-platform code and fake a browser, a phone, a computer, and a smartwatch area unit a similar factor — unless you wish your humanoid and iOS app to be a WebView and your desktop app to be designed with lepton.

There area unit many reasons to not try this, and it’s not the purpose of this piece to convert you to use frameworks like Flutter instead that keep your app native, with all the performance and user expertise blessings that go with it, whereas permitting you to jot down code that's progressing to be a similar for all platforms most of the time.

That requires care and a focus, though, and a minimum of a basic data of the platforms you wish to support, their actual native genus Apis, and every one of that.

React Native users have to be compelled to pay even additional attention thereto as a result of that framework uses the inherent OS widgets, thus you really have to be compelled to pay even additional attention to however the app appearance by testing it extensively on each platforms, while not having the ability to modify between iOS and Material device on the fly like it’s potential with Flutter..

WHAT CHANGES WITHOUT YOUR REQUEST

There are some aspects of the UI of your app that are automatically changed when you switch platforms. This section also mentions what changes between Flutter and React Native in this respect.

Between Android And iOS (Flutter)

Flutter is capable of rendering Material widgets on iOS (and Cupertino (iOS-like) widgets on Android), however what it DOESN’T do is show precisely the same factor on robot and iOS: Material theming particularly adapts to the conventions of every platform.

For instance, navigation animations and transitions and default fonts area unit completely different, however those don’t impact your app that abundant. What might have an effect on a number of your decisions once it involves aesthetics or wife is that the indisputable fact that some static components conjointly modification.

Specifically, some icons modification between the 2 platforms, app bar titles area unit within the middle on iOS and on the left on robot (on the left of the on the market area just in case there's a back button or the button to open a Drawer (explained here within the Material style pointers and conjointly called a hamburger menu). Here’s what a fabric app with a Drawer feels like on Android:

And what the same, very simple, Material app looks like on iOS:

Between Mobile and Web and With Screen Notches (Flutter)

On the online there's a small amount of a unique state of affairs, as mentioned conjointly during this Smashing article regarding Responsive net Development with Flutter: specifically, additionally to having to optimize for larger screens and account for the means folks expect to navigate through your web site — that is that the main focus of that article — you have got to stress regarding the very fact that generally widgets square measure placed outside of the browser window.

Also, some phones have notches within the high a part of their screen or different impediments to the proper viewing of your app attributable to some form of obstruction. Both of those issues may be avoided by wrapping your conveniences during a SafeArea widget, that may be a explicit reasonably cushioning convenience that makes certain your widgets comprise an area wherever they will really be displayed empty preventive the users’ ability to envision them, be it a hardware or code constraint.

IN REACT NATIVE

React Native needs far more attention and a way deeper information of every platform, additionally to requiring you to run the iOS machine furthermore because the mechanical man human at the terribly least so as to be able to check your app on each platforms: it’s not identical and it converts its JavaScript UI parts to platform-specific widgets.

In alternative words, your React Native apps can invariably seem like iOS — with Cupertino UI parts as they're generally known as — and your mechanical man apps can invariably seem like regular Material style mechanical man apps as a result of it’s victimization the platform’s widgets. The distinction here is that Flutter renders its widgets with its own low-level rendering engine, which implies you'll be able to check each app versions on one platform.

Getting Around That Issue

The Other Side: Using The Wrong Widgets For The Right Reasons

But that also means that you can do most of your Flutter development on a Linux or Windows workstation without sacrificing the experience of your iOS users, and then just build the app for the other platform and not have to worry about thoroughly testing it.

Next Steps Cross-platform frameworks are awesome, but they shift responsibility to you, the developer, to understand how each platform works and how to make sure your app adapts and is pleasant to use for your users. Other small things to consider may be, for example, using different descriptions for what might be in essence the same thing if there are different conventions on different platforms.It’s great to not have to build the two (or more) apps separately using different languages, but you still need to keep in mind you are, in essence, building more than one app and that requires thinking about each of the apps you are building.

We will be happy to answer your questions on designing, developing, and deploying comprehensive enterprise web, mobile apps and customized software solutions that best fit your organization needs. As a reputed Software Solutions Developer we have expertise in providing dedicated remote and outsourced technical resources for software services at very nominal cost. Besides experts in full stacks We also build web solutions, mobile apps and work on system integration, performance enhancement, cloud migrations and big data analytics. Don’t hesitate to

get in touch with us!

#b2b ecommerce

#b2bsales

#b2b seo

#b2bservices

#Ecommerce

[secretcupcakesublime]

Solving Common Cross-Platform Issues When Working With Flutter

When mistreatment cross-platform frameworks, folks may forget the nuances of every of the platforms they need their code to run on. This text aims to handle that.

Specifically, people sometimes confuse it with the older Web-based mobile (and desktop) cross-platform frameworks, which basically were just Web pages running within browsers running within a wrapper app.

That was truly cross-platform in the sense that the interfaces were the same anyway because you only had access to the interfaces normally accessible on the Web.

Flutter isn’t that, though: it runs natively on each platform, and it means each app runs just like it would run if it were written in Java/Kotlin or Objective-C/Swift on Android and iOS, pretty much. You need to know that because this implies that you need to take care of the many differences between these very diverse platforms.

Example 1: Storage

I recently wrote on my diary concerning the necessity for a special approach to storing JWTs in net apps compared to mobile apps. That is due to the various nature of the platforms’ storage choices, and therefore the got to recognize every and their native development tools.

WEB

When you write a Web app, the storage options you have are:

1. Downloading/uploading files to/from disk, which requires user interaction and is therefore only suitable for files meant to be read or created by the user.

2. Using cookies, which may or may not be accessible from JS (depending on whether or not they’re httpOnly) and are automatically sent along with requests to a given domain and saved when they come as part of a response.

3. Using JS localStorage and sessionStorage, accessible by any JS on the website, but only from JS that is part of the pages of that website.

MOBILE

The situation when it comes to mobile apps is completely different. The storage options are the following:

1. Local app documents or cache storage, accessible by that app.

2. Other local storage paths for user-created/readable files.

3. NSUserDefaults and SharedPreferences respectively on iOS and Android for key-value storage.

4. Keychain on iOS and KeyStore on Android for secure storage of, respectively, any data and cryptographic keys.

If you don’t recognize that, you’re getting to build a multitude of your implementations as a result of you would like to understand what storage answer you’re truly exploitation and what the benefits and downsides area unit.

CROSS-PLATFORM SOLUTIONS: AN INITIAL APPROACH

Using the Flutter shared_preferences package uses localStorage on the Web, SharedPreferences on Android and NSUserDefaults on iOS. Those have utterly completely different implications for your app, particularly if you’re storing sensitive info like session tokens: localStorage are often scan by the shopper, thus it’s a tangle if you’re prone to XSS. although mobile apps aren’t very prone to XSS, SharedPreferences and NSUserDefaults don't seem to be secure storage ways as a result of they will be compromised on the shopper facet since they're not secure storage and not encrypted.  That’s as a result of they're meant for user preferences, as mentioned here within the case of iOS and here within the robot documentation once talking concerning the protection library that is meant to produce wrappers to the SharedPreferences specifically to inscribe the info before storing it.

SECURE STORAGE ON MOBILE

The only secure storage solutions on mobile are Keychain and KeyStore on iOS and Android respectively, whereas there is no secure storage on the Web. The Keychain and KeyStore area unit terribly completely different in nature, though: Keychain could be a generic credentials storage resolution, whereas the KeyStore is employed to store (and will generate) science keys, either stellate keys or public/private keys.

This means that if, for example, you would like to store a session token, on iOS you'll be able to let the OS manage the coding half and simply send your token to the Keychain, whereas on humanoid it’s a small amount a lot of of a manual expertise as a result of you would like to get (not hard-code, that’s bad) a key, use it to cypher the token, store the encrypted token in SharedPreferences and store the key within the KeyStore. There area unit completely different approaches to it, as area unit most things in security, however the only is perhaps to use stellate coding, as there's no want for public key cryptography since your app each encrypts and decrypts the token. Obviously, you don’t have to be compelled to write mobile platform-specific code that will all of that, as  there is a Flutter plugin that does all of that, for instance.

THE LACK OF SECURE STORAGE ON THE WEB

That was, actually, the rationale that compelled ME to put in writing this post. I wrote regarding exploitation that package to store JWT on mobile apps and other people wished the net version of that however, as I said, there's no secure storage on the net. It doesn’t exist. Does that mean your JWT must be get in the open? No, not at all. you'll be able to use httpOnly cookies, can’t you? Those area unitn’t accessible by JS and are sent solely to your server. the problem thereupon is that they’re continuously sent to your server, notwithstanding one amongst your users clicks on a GET request address on somebody else’s web site which GET request has aspect effects you or your user won’t like. This really works for different request varieties moreover, it’s simply a lot of sophisticated. It’s referred to as Cross-Site Request Forgery and you don’t wish that.  It’s among the net security threats mentioned in Mozilla’s MDN docs, wherever you'll be able to notice a a lot of complete rationalization. There area unit interference strategies. the foremost common one has 2 tokens, actually: one amongst them aiming to the shopper as Associate in Nursing httpOnly cookie, the opposite as a part of the response.  The latter must be hold on in localStorage and not in cookies as a result of we have a tendency to don’t wish it to be sent mechanically to the server.

SOLVING BOTH

What if you have both a mobile app and a Web app? That can be dealt with in one of two ways:

1. Use the same backend endpoint, but manually get and send the cookies using the cookie-related HTTP headers;

2. Create a separate non-Web backend endpoint that generates different token than either token used by the Web app and then allow for regular JWT authorization if the client is able to provide the mobile-only token.

Running Different Code On Different Platforms

Now, let’s see how we can run different code on different platforms in order to be able to compensate for the differences.

CREATING A FLUTTER PLUGIN

Especially to unravel the matter of storage, a technique you'll do this is with a plugin package: plugins offer a typical Dart interface and might run totally different code on different platforms, together with native platform-specific Kotlin/Java or Swift/Objective-C code. Developing packages and plugins is quite complicated, however it’s explained in several places on the net et al. (for example in Flutter books), together with the official Flutter documentation. For mobile platforms, for example, there already may be a secure storage plugin, and that’s flutter_secure_storage, that you'll notice associate example of usage here, however that doesn’t work on the net, as an example.

On the opposite hand, for easy key-value storage that additionally works on the net, there’s a cross-platform Google-developed first-party plugin package known as shared_preferences, that incorporates a Web-specific part known as shared_preferences_web that uses NSUserDefaults, SharedPreferences or localStorage reckoning on the platform.

TARGETPLATFORM ON FLUTTER

After importing package:flutter/foundation.dart, you can compare Theme.of(context).platform to the values:

TargetPlatform.android

TargetPlatform.iOS

TargetPlatform.linux

TargetPlatform.windows

TargetPlatform.macOS

TargetPlatform.fuchsia

and write your functions so that, for each platform you want to support, they do the appropriate thing. This will come especially useful for the next example of platform difference, and that is differences in how widgets are displayed on different platforms.

For that use case, in particular, there is also a reasonably popular flutter_platform_widgets plugin, which simplifies the development of platform-aware widgets.

Example 2: Differences In How The Same Widget Is Displayed

You can’t simply write cross-platform code and fake a browser, a phone, a computer, and a smartwatch area unit a similar factor — unless you wish your humanoid and iOS app to be a WebView and your desktop app to be designed with lepton.

There area unit many reasons to not try this, and it’s not the purpose of this piece to convert you to use frameworks like Flutter instead that keep your app native, with all the performance and user expertise blessings that go with it, whereas permitting you to jot down code that's progressing to be a similar for all platforms most of the time.

That requires care and a focus, though, and a minimum of a basic data of the platforms you wish to support, their actual native genus Apis, and every one of that.

React Native users have to be compelled to pay even additional attention thereto as a result of that framework uses the inherent OS widgets, thus you really have to be compelled to pay even additional attention to however the app appearance by testing it extensively on each platforms, while not having the ability to modify between iOS and Material device on the fly like it’s potential with Flutter..

WHAT CHANGES WITHOUT YOUR REQUEST

There are some aspects of the UI of your app that are automatically changed when you switch platforms. This section also mentions what changes between Flutter and React Native in this respect.

Between Android And iOS (Flutter)

Flutter is capable of rendering Material widgets on iOS (and Cupertino (iOS-like) widgets on Android), however what it DOESN’T do is show precisely the same factor on robot and iOS: Material theming particularly adapts to the conventions of every platform.

For instance, navigation animations and transitions and default fonts area unit completely different, however those don’t impact your app that abundant. What might have an effect on a number of your decisions once it involves aesthetics or wife is that the indisputable fact that some static components conjointly modification.

Specifically, some icons modification between the 2 platforms, app bar titles area unit within the middle on iOS and on the left on robot (on the left of the on the market area just in case there's a back button or the button to open a Drawer (explained here within the Material style pointers and conjointly called a hamburger menu). Here’s what a fabric app with a Drawer feels like on Android:

And what the same, very simple, Material app looks like on iOS:

Between Mobile and Web and With Screen Notches (Flutter)

On the online there's a small amount of a unique state of affairs, as mentioned conjointly during this Smashing article regarding Responsive net Development with Flutter: specifically, additionally to having to optimize for larger screens and account for the means folks expect to navigate through your web site — that is that the main focus of that article — you have got to stress regarding the very fact that generally widgets square measure placed outside of the browser window.

Also, some phones have notches within the high a part of their screen or different impediments to the proper viewing of your app attributable to some form of obstruction. Both of those issues may be avoided by wrapping your conveniences during a SafeArea widget, that may be a explicit reasonably cushioning convenience that makes certain your widgets comprise an area wherever they will really be displayed empty preventive the users’ ability to envision them, be it a hardware or code constraint.

IN REACT NATIVE

React Native needs far more attention and a way deeper information of every platform, additionally to requiring you to run the iOS machine furthermore because the mechanical man human at the terribly least so as to be able to check your app on each platforms: it’s not identical and it converts its JavaScript UI parts to platform-specific widgets.

In alternative words, your React Native apps can invariably seem like iOS — with Cupertino UI parts as they're generally known as — and your mechanical man apps can invariably seem like regular Material style mechanical man apps as a result of it’s victimization the platform’s widgets. The distinction here is that Flutter renders its widgets with its own low-level rendering engine, which implies you'll be able to check each app versions on one platform.

Getting Around That Issue

The Other Side: Using The Wrong Widgets For The Right Reasons

But that also means that you can do most of your Flutter development on a Linux or Windows workstation without sacrificing the experience of your iOS users, and then just build the app for the other platform and not have to worry about thoroughly testing it.

Next Steps Cross-platform frameworks are awesome, but they shift responsibility to you, the developer, to understand how each platform works and how to make sure your app adapts and is pleasant to use for your users. Other small things to consider may be, for example, using different descriptions for what might be in essence the same thing if there are different conventions on different platforms.It’s great to not have to build the two (or more) apps separately using different languages, but you still need to keep in mind you are, in essence, building more than one app and that requires thinking about each of the apps you are building.

We will be happy to answer your questions on designing, developing, and deploying comprehensive enterprise web, mobile apps and customized software solutions that best fit your organization needs. As a reputed Software Solutions Developer we have expertise in providing dedicated remote and outsourced technical resources for software services at very nominal cost. Besides experts in full stacks We also build web solutions, mobile apps and work on system integration, performance enhancement, cloud migrations and big data analytics. Don’t hesitate to

get in touch with us!

[thahxa]

C++ honestly... isn't that great if you wanna force people to micromanage their computer tbh.

In theory it can be, since you can manually manage memory with free and delete, but modern C++ has the STL (eg. <vector>, <map>) so you don't have to think too much about data structures, and it even has smart pointers, so you can almost never think about managing memory yourself as well.

In addition, it really is a bloated language, and while this can be ok-ish for some purposes, it makes it a pretty bad one to learn programming in, especially if you want to teach both manual memory management and object-oriented programming, and so you end up with students having to worry about bits of both, in addition to juggling the STL and the rest of the (very) bloated language.

If you just want to teach manual memory management for "intro to programming", C is almost definitely a better choice, being both much simpler (both in terms of syntax and libraries available) and also being much more explicit (which is probably something you want to do if you want to teach memory management)

And of course in real life programming you want to use neither and pick a language that either has a garbage collector (like Go or Kotlin) or actually manages memory in a sane way (ie. Rust or "C++ but you're forced to use smart pointers")

@transunlight I would say almost the exact opposite.

Python is bad for competitive programming but it's good for new programmers, and once you learn in Python, the techniques you've learned can and will transfer over to other languages (they currently are for me with Rust).

I don't think new coders should learn C++ unless we want them to hate coding. Rust... I would wait until they have the knowledge to appreciate it more - it's a tough difficulty curve unless you understand what it's trying to accomplish.

Codeforces has a much higher barrier to entry - there's the aforementioned language issue, but there's also the issue of editing locally vs in the browser and requiring a fast IO setup, both of which aren't bad to do but are kind of a pain in the ass the first time.

Editorials on codeforces are written for people with a fair amount of knowledge, whereas discussions on leetcode are written by and for beginners. This has its pros and its cons, but initially it's definitely preferable for new coders.

Competitions are shorter and easier on leetcode, which is less of a commitment and less discouraging. If you're a Div 4 level coder, would you rather have 1.5 leetcode competitions a week that you can at least solve a couple problems in 90 minutes, or a Div 4 competition every few months and tons of Div 2 competitions where you can solve 1 problem out of 6 over 2 hours?

To summarize: I think lots of new people would be turned off from codeforces initially but enjoy leetcode and eventually make the transition back to codeforces after getting some experience (that's what I'm doing). But I don't think there's anyone brand new who would hate leetcode but love codeforces.

[joeyrob1]

Software Development Trends – Looking Forward To 2020

Credit: Image by Pexels from Pixabay

In an industry where continual advancements and innovations are the norms, it has become crucial to match this pace of development. In 2019, Gartner projected worldwide IT spending to reach $3.79 trillion.

Those who are aware of the inclinations of the market will have a significant edge over their competitors. Given below are the top five software development trends for the year 2020, so that you can take advantage of them:

Demand for Internet of Things (IoT) to rise

You would have seen IoT appearing in every software development trend list for quite some time. The reason is that this technology will continue to play a huge role in the next few years. IoT refers to smart devices that can connect and transfer data via the internet.

IoT is a game-changer, as it opens up the possibility of providing secure, user-friendly, and reliable solutions with software development. For both business owners and developers, this technology has countless opportunities. The prediction is that by 2025, the number of IoT connected devices is going to reach 75.44 billion.

Greater integration of artificial intelligence

For several years, artificial intelligence (AI) has always been a buzzword. However, with the constant evolution of this technology, along with an increase in adoption rates indicate that it is going to play a crucial role in 2020.

A survey by The Boston Consulting Group and MIT Sloan Management Review found that 85% of its participants believe AI will give them a competitive advantage. Revenue from this technology worldwide has a projection of $190 billion by 2025.

Deep learning and machine learning have immense number of applications in various industries. Chatbots are becoming a trend among companies, as they include these bots in websites and applications. With the help of artificial intelligence, they offer better benefits, when compared to human customer service representatives.

Over time, this technology will help analyze customer behavior accurately, while reducing the dependence on human resources. The goal is to maximize speed, reliability, and accuracy of the predictions.

Increase in demand for cross-platform development

Although native apps come with their set of advantages, companies are preferring to invest in cross-platform development. Organizations and developers are learning about the latest programming languages and frameworks to make better use of this technology.

One major reason for this shift is reduction in operating costs. At the same time, it brings down resource investment, as companies only have to focus on a single project, rather than multiple ventures. Even though environments such as Xamarin and Flutter have been there for a long time, only now has it become efficient to integrate them.

Another example is Scala and Kotlin in Android development. Developers are preferring to use these programming languages over JAVA, as it offers functional and object-oriented programming.

Progressive Web Apps sets the standard

Progressive Web Apps (PWA) are going to be the golden standard in 2020 for businesses worldwide. The reason is that these applications offer incredible user experience while being up-to-date simultaneously.

The design of these tools is to offer app-like experience to the users, even though they are using browsers. When it comes to a website, bad UI/UX can bring down your conversion rates. On top of that, you can’t make the most of your user’s hardware specifications, to improve performance.

With PWA, you get the best of websites and applications, while offering an excellent experience to your customers. It can bring down the bounce rates while improving the conversion rates.

PWA is growing in popularity because it cuts down distribution and development costs for businesses. On top of that, it improves search engine optimization (SEO) and uses lesser data. You don’t need to update it constantly and provides better visitor experience, which in turn increases conversion rates.

Software development with cloud computing

The introduction of cloud technology changed the way businesses operate. It offers solutions to conventional storage problems while ensuring the service is secure and reliable. In 2020, there will be an increase in using cloud computing for the software development process.

The advantage is that it makes the project transparent, increases speed of development and brings down project costs. Cloud computing variants such as Software-as-a-service (SaaS), Infrastructure-as-a-service (IaaS), and Platform-as-a-service (PaaS) is already in use. These types of technology improve efficiency when it comes to development. For example, PaaS is useful for businesses as they can create and run apps, without having to build them.

These are the software development trends you should look forward to, in the year 2020. It gives you an idea of where this industry will head in the future.

If you are a business owner, you need to make the most of these advancements so that you can stay ahead of your competition. It helps increase your sales, improve user experience, and cut down on operating costs.

One way to make sure you can make the most of the latest software development trends is to outsource your tech projects. Get in touch with RobustTechHouse to see how you can benefit from a partnership with an outsourcing vendor!

Software Development Trends – Looking Forward To 2020 was originally published on RobustTechHouse - Mobile App Development Singapore