Thewebcraft's Posts
Nairaland Forum › Thewebcraft's Profile › Thewebcraft's Posts
1 2 3 4 5 6 7 8 9 10 (of 10 pages)
directonpc:I guess you didnt read the post this is not the place to criticize hybrid apps besides your UI is too poor for a native app and you are still complaining about webview "saying because it sucks" your app looks like a 12 year old designed it. This app below is built with HTML, CSS, Javascript and JAVA and your so called native app doesn't meet the features.
|
try array_values function: $array = array_values($myarray); |
ogheneserome:ok 08102064720 |
ogheneserome: dont know where you can learn in Ikeja (Stay there too)... |
FincoApps:http://ionicframework.com [AngularJS] works well on android 2x |
lordZOUGA:http://ionicframework.com/showcase |
Hybrid HTML5 mobile apps seem to get a bit of a bad rap, it’s not really justified though. If you speak to most native mobile app developers they will tell you that hybrid applications are: Only good for building quick prototypes Slower and less performant than native applications Not real mobile apps It’s not always just the native developers though, if you speak to people who have actually tried creating hybrid apps with HTML5 and PhoneGap you will often get a similar response. I’ve seen, built and used amazing applications that were built with HTML5 and PhoneGap, which look and feel just like native apps (good ones at that). These apps aren’t freaks of techology, they are complex apps built by good developers who know their tools. You would absolutely not be able to tell that these apps weren’t native (except for maybe the fact that UNTAPPD is available on four different smart phone platforms). So, my question remains. Why do HTML5 mobile apps get such a bad rap? 1. It’s REALLY Easy to Create Bad HTML5 Mobile Apps It’s so easy to create a HTML5 mobile application, and that’s where a lot of its reputation comes from. If you take someone who is reasonably comfortable with HTML, CSS and JavaScript but has never built a mobile application before they could probably piece together a simple mobile app in a day or two using HTML5. Why is this a problem? * Someone who has never built a mobile app before will likely not understand how to design a suitable interface with a good user experience * They also won’t understand the limitations of a mobile app and how to overcome performance issues * They may assume they can do things the way they would do it normally on the web * They may not understand general programming principles * The resulting app is probably going to be pretty bad, and exhibit those stereotypical HTML5 problems Now I don’t want to vilify web developers who jump right in and start creating bad mobile apps, that’s exactly what they should be doing and it’s a great way to learn. But if you take the same person and get them to try to create a native app, they have to learn a whole new language and way of doing things. It’s going to take a lot longer until they are even able to produce a working mobile app, but by that time they will have quite a bit of experience and most of the developers who aren’t quite ready to build a mobile application yet will probably never make it that far. So we end up with someone who has smashed out a HTML5 mobile app, thought “wow, this is pretty awful” switched to native and produced a superior result. This causes a disproportionate amount of bad HTML5 applications when compared to bad native applications. Conclusion: Hybrid apps have poor performance. If we take that same developer, and get them to spend some time really understanding how to create high performance HTML5 mobile applications, then the result would be a lot better. Native forces you to make good applications, HTML5 allows you to make good applications That’s not to say that all native apps are good, I’ve seen some pretty awful ones, but in general there is a larger proportion of good native apps. It’s kind of similar to the situation with the PHP programming language. It’s a very beginner friendly language that is pretty relaxed on the rules, so it attracts a lot of beginners who make bad applications with it. But if you take someone who knows how to use PHP properly, then it is a very capable language (and that person will probably have to deal with people on Internet forums telling them how bad PHP is). 2. If You Don’t Use a Framework, a Good One, Then You Will Get Poor Results It’s so important to use a good HTML5 framework. These frameworks (the good ones) are built specifically to deal with the shortcomings of HTML5, specifically things like: * Tap Delay * Memory Usage * Animations * DOM Manipulation so that you can focus on just building your app. There’s so many little things that these frameworks take care of to make sure you can produce a smooth, native like experience that it’s completely unfeasible to build a good HTML5 mobile app without one (unless you’ve got some serious coder-power). Naturally, some frameworks are better than others. jQuery is quite popular since most people are already familiar with it, but it doesn’t perform as well on mobile as other frameworks do. Ionic is based on AngularJS which works very well for mobile. 3. People Don’t Think Hybrid HTML5 Apps Have Offline Capability There’s two parts to this assumption usually: People assume that hybrid apps require an Internet connection to function People don’t think hybrid apps have the ability to store data offline Addressing the first assumption, that’s simply not the case. A HTML5 mobile application can be packaged with PhoneGap and distributed through app stores. All the applications files are stored in the application, along with a built in browser, and there is no need to access the Internet to run the application (unless of course the app uses the Internet). On the second assumption, the default storage for HTML5 apps is usually the browsers local storage. This isn’t bad, and is usually quite suitable for most apps but it does have size limitations and can be unreliable. One solution to this is to store the data on a server and retrieve it in the application when necessary, but then what if you want to allow your users to use the app offline as well? There are solutions for this. First of all HTML5 mobile applications can quite easily access native like storage by using the SQLite PhoneGap plugin, and if the app requires syncing online and offline data you can use something like PouchDB. 4. People Think HTML5 Can’t Do as Much as Native Apps As an extension to the last point, some people don’t realise that a hybrid HTML5 app can do everything a native app can do. This includes things like: Accessing any part of the device. Basics: * Using the devices camera * Using BlueTooth * Running tasks in the background * Receiving Push Notifications * In App Purchases * Game Center Integration Typically PhoneGap is used when building HTML5 mobile apps and the PhoneGap native wrapper is a native app. So the HTML5 mobile application can access everything a normal native application can by using PhoneGap as a middle man. HTML5 app interacting with the device If you want to learn more about how PhoneGap works you can check out the website. 5. Elitism This is a cultural problem in the programming community, and a very ugly one. These debates and flamewars go back forever: HTML5 vs Native, Mac vs PC, PHP vs Ruby and so on. Many people believe that whatever thing they pick is the right thing, and anybody who uses the other thing is clearly an idiot. It’s great to discuss and debate the strengths and weaknesses of different approaches, but often these discussions devolve into an “us vs them” mentality and it quickly becomes completely unproductive. People become emotionally invested in the programming languages they choose, and when you might devote years to learning something this is completely understandable – nobody wants to be on the “losing” side. The more sinister side of this is that for some people there is an element of self preservation. If you know one particular tech really well, and something comes up to rival it then it is in your interest to make that tech go away. What if your clients start coming to you and saying: Can you do HTML5? We want to release our apps on multiple platforms that would be pretty bad for an Objective-C based business, so it would make sense for Objective-C developers to make their clients (and the general population) believe that HTML5 is not a viable option or that nobody really uses Android anyway. I don’t believe that this is some war where one side will win out in the end, different goals call for different solutions. Sometimes that solution will be native, sometimes that solution will be HTML5, a lot of the time it won’t matter which approach is used. 6. People Don’t Know Good HTML5 Apps Are Created with HTML5 It’s not hard to spot a poorly built HTML5 app, but it is hard to spot a good HTML5 app because… you can’t tell the difference between it and a native app (and that’s exactly the point). So if people see a poorly built mobile app they assume it’s built with HTML5, and if they see an awesome mobile app they assume it’s native. This reinforces that misconception that well performing apps are built natively, and poor performing applications are built with HTML5. Your thoughts? My view is that for most mobile applications a HTML5 / Hybrid approach is more than suitable, you would rarely ever be able to tell the difference if it is built well, and it has the huge added bonus of being able to be deployed to multiple platforms. I don’t think that means that native applications are going anywhere though, I think native will be required for specialised applications for a long time to come, and for some teams a workflow of creating two native apps may be preferable and workable. When comparing one solution to another the only legitimate concern is the end goal. How you get there just comes down to what works for you or your team. It’d be great to hear some thoughts from both HTML5 and Native developers in the comments, but can we all just get along? |
JoelAmawhe:One of my students designed this, Firefox tabs page.
|
pizel:visit the Google playstore to see the top downloaded games (by genre) that should give you an idea of what people are looking for. |
Nice ![]() |
ogheneserome:6 months should be ok to be a beginner, you can develop mobile apps depending on how fast you learn (I started from web dev.) just get some really good books for a start, what do you really want to do, Mobile, Web or both..? |
53cur3m0d3: |
FincoApps:You're Welcome. |
FincoApps:Hey Bro check ur css file...... YourSite.com/wp-content/plugins/js_composer/assets/css/js_composer.css On line 14685 .wpb_animate_when_almost_visible { opacity: 0; } remove the opacity. |
Well like a calculator, currency converter, quiz.. etc |
clevadani:I didnt understand JavaScript by reading the book from cover to cover but I understood JavaScript better by practice e.g after knowing what a variable or function does, I used it to create a simple program. that's the best way to learn it, so I suggest you use that approach to save time. |
nollyj:Nice One Bro. |
overhypedsteve:You're Welcome |
Very Nice ![]() |
You’re Not Too Tired To Create. You’re Too Distracted. First of all HBD to me. “I’m too tired.” Too many of my first projects have died an early death because of that sentence. This is an excuse that neatly covers failure for just about any work. It’s so easy to justify. But just because an excuse is justifiable doesn’t mean it’s worthwhile. Because I can always imagine a time when I’ll feel more refreshed and more energized, “I’m too tired” can ruin any chance I have to make something. What to do, then? Run a few laps? Get more sleep? Drink five Red Bulls? (The last one only works for most of my developer friends — don’t try it). Half of the real problem of exhaustion comes from distraction. The problem is not being too tired. The problem is having a divided mind. Most of us probably have a dozen different projects going on at the same time — or worse, left ignored. This saps our confidence that we can do new work well (or completely). It keeps us from reaching the creative focus needed to get into the flow states that make work fun. The solution I’ve found? If I want real momentum in starting something, I have to finish something. I can only start from where I left off, so I begin by fulfilling the goals or obligations I’ve left halfway to completion. As simple as this solution sounds, getting the mental space to start something new is rarely as easy as checking off the last item on my to-do list. I have to ask myself a few questions first: Where does this work fit into my priorities? — Completing old work should remove a stress point or obligation, or it should make starting new work simpler. How long will it take me to complete this? — Since my main goal is to begin something new, I want to tackle something I can finish in a reasonable amount of time. What mental roadblocks are holding me back from finishing this? — Odds are, they’re the same ones — analysis paralysis, fear of embarrassment, fear of negative feedback — that will do even more to hold me back from starting something. When I have the answers for these questions, I know what to take on first. That takes some of the uncertainty out of sitting down to start a work session. More importantly, once I have the forward momentum of having done something important, starting something new doesn’t seem nearly so hard. And when I’ve done something really cool or worth sharing, I don’t feel nearly as tired. What excuses are holding you back from doing great work? Don’t just procrastinate or force yourself to run up against walls — rethink the source of your problem with the work. The solution may be counterintuitive: like me, maybe you need to finish things before you can start them. |
phrezzz:Yes he is, I also think he is on the right path but he should still find out time to learn some basic languages for web n App dev. |
I hate it when developers argue about stupid, meaningful topics like this when we can talk about something serious... "What Are The Differences Between Programming And Coding"mtcheeeeww.... |
UI/UX, Debugging and Full functionality (Coding) is what I like, my web or mobile apps can never look the same, Just don't like Documenting... |
Hello Use this, it works. <html> <head> </head> <body> <input type="text" id="url" placeholder="Enter an address"/> <input type="submit" onclick="viewSource();" value="View Source"/> <script language="javascript"type="text/javascript"> function viewSource(){ //You dont need a form for that this loads a new page and views the source.. window.location.href="view-source:"+document.getElementById('url').value; } </script> </body> </html> |
One of the most common questions I get from students is: “What’s the best way to retain what I’m learning?” Students may think they understand the lessons and concepts being taught, but later struggle putting it all into practice. Writing good code takes a lot of time and effort, so the best way to retain the information is through practice and repetition –– easier said than done, right? Let’s go over some helpful tools and methods you can use to better retain what you’re learning. It’s Easy to Forget What You Don’t Understand Often, even when you think you have a good grasp of HTML, CSS, or JavaScript concepts and techniques, they’re difficult to put it into practice. And sometimes, no matter how clear the explanations in the videos or tutorials, you can’t get anything to work when you try it later on. Don’t Just Watch or Read Be an active learner, not a passive learner. It’s difficult to retain information through passive learning. You may think that watching a video or reading a tutorial over and over again is enough to lodge the information in your head forever. While some of it will eventually stick, it’s not the most effective way to learn. Even though you’re focused on what’s being taught in the lesson, you’re just seeing or reading abstract concepts. To really get it, you need to run into difficulty, make mistakes, then identify and correct them. So converting that knowledge from abstract to practical is important because it’s no longer something someone else has told you. Start building something right away: A single-page website, a small website component, get involved in a project –– anything. It doesn’t matter what it looks like or how it works as long as you keep doing it while raising the bar, you’ll gradually get better. I promise! Online Coding Tools These days, online code editors like CodePen, JSFiddle provide designers and developers a quick way to communally experiment with code. This is a helpful way of implementing a concept you just learned. To ensure you’re getting it into your long-term memory, try coding at different times during the day, without looking anything up beforehand. Developer Tools When visiting websites I like, I always use Chrome DevTools (or Mozilla’s Firebug) to inspect the code and see how certain parts of it were built. I’ve learned some neat things doing that. Also, viewing –– or “borrowing” –– another website’s HTML and CSS, then changing it around to build something different can really help when learning to code. Share Your Knowledge “But I’m not an expert!” It doesn’t matter. You will always know something that someone else doesn’t know. Plus, you’ll retain more when you synthesize then teach the information and, down the road, it might even establish you as the “expert” in a given topic. I’m always impressed by people who have blogs where they write about what they’re learning. It’s no coincidence they are the ones who find successful work in the industry. Be Patient, Confident and Don’t Worry About Memorizing It’s important to be patient because it takes a while to wrap your head around code, but the more you do it, the more it starts clicking. Don’t worry about memorizing every tag, selector, property or value available. A solid understanding of the concepts –– and a reliable reference –– is more important. I probably don’t know every CSS selector off the top of my head, but I sure know how they work and where to reference them. Finally, to retain new concepts, you need to be confident and refrain from being pessimistic when you struggle. Pessimism leads to giving up. |
How you should choose a programming language: don’t. Wait . . . what about the high paying tech jobs and flexible work schedules out there? Isn’t this the best time to learn how to code? It is, and you should. Many people are curious about learning to code, and, naturally, people want to know where to start. This leads to the which programming language should I choose hurdle. Choosing a programming language is an obstacle, because you probably don’t have the information necessary to make a good decision. As someone who has never written a line of code, you are throwing a dart at the board and hoping for the best. I encourage you to think a little bit more about what you want to accomplish with code. Be specific. Getting a good job isn’t precise enough. After all, is a job good if it pays well but you hate it? Code is everywhere, and that means you have a lot of options. Do you want to get a job building mobile apps? Did you read a bit about the Arduino and Raspberry Pi that sparked your interest? Are you a researcher who wants a little more command over your data? You can do a lot with code, and the opportunities continue to expand. Once you take the time to think about what you want to do, build, study, etc. you can start thinking about which language to learn. Now, there are always options, and there will still be confusion—more on that later. However, languages have strengths or have been adopted more regularly in certain fields. This means that by picking a project or goal you have drastically reduced the number of targets on the dartboard. I know I’m making it sound simple. It’s hard enough to decide what you want to do. Once you get a general idea, then it can become more confusing. Let’s say you want to work at building Web apps. Great, now you just Google the languages used to make Web apps, and then … you … you find a forum post that … OK … PHP seems popular … but Ruby also … well, this person with a TON of Twitter followers says … AHHHHH … FORGET IT! People will tell you to learn JavaScript or PHP first, then someone will tell you that Python’s syntax is simpler and you should start with it. Then you’ll hear about Java and all the available jobs, plus Java is used for Android apps. It goes on and on. Picking a project to build or a career track helps narrow the search, but there’s a lot of confusion left. So what to do? You could keep refining. Maybe there’s a company you want to work for. What are they using? You might get a general idea from stackshare, which is a site that shows the tech stack (the different pieces that come together to make the service you use) of many companies. Some other beneficial resources include Stack Overflow and Reddit. Unfortunately, those forums can lead to some of the confusing answers mentioned earlier. I suggest asking someone you trust. Go find someone in person. Attend a Meetup and ask the people working in the field what they recommend. You’ll find that people are much more willing to engage meaningfully in person. You can also ask the all-important follow-up questions much easier when face-to-face. So, yes, research is your friend, but I don’t want you to go away feeling like you’ve been told to get help elsewhere. So here is a list of some general guidelines and information about some of the languages you will likely find in the wild. My Oversimplified General Guidelines to save you some Googling HTML/CSS: People often begin by learning HTML and CSS. Why? These two languages are the essentials for creating static Web pages. HTML (Hypertext Markup Language) makes up all the text, links, and other content you see on a Web site. HTML is the language that structures a Web page. CSS is the language that makes what you see on a Web page look the way it does—color, layout, other visual niceties. Why not just tell you to start with HTML and CSS? You may not be interested in creating content for the Web. As I said earlier, you can do a lot with coding, and the Web is just part of it. However, if you are interested in coding for the Web, definitely start with HTML and CSS. JavaScript JavaScript is a first programming language for many people. This is because it is the logical next step after learning HTML and CSS. JavaScript provides the behavior on a Web site. For example, when you see a form field turn red to indicate that you haven’t filled it out properly, that’s probably JavaScript at work. JavaScript has become increasingly popular, and it now lives outside of the Web browser. You will be in a good place by learning JavaScript as it continues to become more popular and multi-purpose over time. Java Despite its name, Java is not really related to JavaScript in any meaningful way. JavaScript was named when Java was becoming popular. Some marketing minds of the time decided to confuse us all in an attempt to make the LiveScript language more popular by changing its name to JavaScript. Just remember that Java is not JavaScript. Java is a widely used language that can be used for anything from Web applications to desktop and mobile applications. Java is the language of choice for developing Android applications, so it might be the right choice if you want to start making mobile apps. Objective-C Like Java, Objective-C can be used to write desktop applications and mobile apps. However, Objective-C is essentially Apple territory. Until the recent release of the Swift programming language, Objective-C was the language for developing native iPhone and iPad apps. Many major apps are still written in Objective-C (and will continue to be for quite a while), and programmers for these apps are in high-demand. If you want to work on iPhone and iPad apps for a larger company, it’s a good idea to learn Objective-C. Swift Swift was released in June of 2014 by Apple as a modern language for developing Mac Desktop applications and iPad, iPhone, and Apple Watch applications. If you want to get into the world of iOS, Swift is the the language with which Apple intends to move forward. Yes, many apps are already written in Objective-C, but Swift is here to stay. PHP PHP is one of the most popular Web languages. It runs massive sites and is used by heavy hitters such as Facebook and Etsy. PHP is also the language used to write WordPress and Drupal. Because of its popularity, learning PHP will serve you well if you intend to code for the Web. Python Python is a general-purpose language used for everything from server automation to data science. Python is a great language for beginners, because it is easy to read and understand. You can also do so many things with Python that it’s easy to stick with the language for quite a while before needing something else. Python finds itself at home both creating Web apps like Instagram and assisting researchers in making sense of their data. Ruby Ruby is often associated with the Rails framework that helped popularize it. Used widely among Web startups and big companies alike, Ruby and Rails jobs are pretty easy to come by. Ruby and Rails makes it easy to get an idea into a working application, and it has been used to bring us Twitter, GitHub, e.t.c. Don’t Worry Fear not, choosing a programming language may still seem overwhelming. It shouldn’t be, because you can’t go wrong. As long as you choose a language that is regularly used in tech today, you’ll be in a good place. When you are starting out, the goal is to become solid in the basics, and the basics are pretty similar across almost all modern programming languages. Part of learning to code is learning a language’s syntax. A much bigger part of learning to code, the part that takes longer and gives you more headaches, is learning to problem solve like a programmer. You can learn the grammatical structure of the English language pretty quickly; however, it is not until you put that grammatical structure to use in a conversation that you truly understand the language. The same is true in programming. You want to learn the core concepts in order to solve problems. Doing this in one language is similar to doing it in another. Because the core concepts are so similar from language to language, I recommend that whatever language you pick, you stick with it for a while. There are still sticking points No matter what you choose, it will be challenging at first. Stick with it. However, recognize when a sticking point is caused by the simple fact that you’re learning something new rather than the feeling that you aren’t interested in what you are creating. The benefits to picking a language and sticking with it for a bit have been true for me. But don’t forget the first point–do your best to pick a project or two that interests you. The Takeaway It’s a wonderful time to learn how to code. I have never been served poorly by trying to learn something. Don’t worry if you don’t like the language you picked. You haven’t wasted any time. Pick up, dust off, and on to the next one. So good luck in your coding journey. |
Google63:Yeah do all these until your passion dies.... mtcheeeewww... |
pcguru1: thats how our job is you just have to keep up with the latest |
Bootstrap 4 has been a massive undertaking that touches nearly every line of code. We’re stoked to share it with you and hear your feedback. We’ve got a lot of news to share with you, so let’s jump right into it. What’s new There are a ton of major changes to Bootstrap and it’s impossible to cover them all in detail here, so here are some of our favorite highlights: Moved from Less to Sass. Bootstrap now compiles faster than ever thanks to Libsass, and we join an increasingly large community of Sass developers. Improved grid system. We’ve added a new grid tier to better target mobile devices and completely overhauled our semantic mixins. Opt-in flexbox support is here. The future is now—switch a boolean variable and recompile your CSS to take advantage of a flexbox-based grid system and components. Dropped wells, thumbnails, and panels for cards. Cards are a brand new component to Bootstrap, but they’ll feel super familiar as they do nearly everything wells, thumbnails, and panels did, only better. Consolidated all our HTML resets into a new module, Reboot. Reboot steps in where Normalize.css stops, giving you more opinionated resets like box-sizing: border-box, margin tweaks, and more all in a single Sass file. Brand new customization options. Instead of relegating style embellishments like gradients, transitions, shadows, and more to a separate stylesheet like v3, we’ve moved all those options into Sass variables. Want default transitions on everything or to disable rounded corners? Simply update a variable and recompile. Dropped IE8 support and moved to rem and em units. Dropping support for IE8 means we can take advantage of the best parts of CSS without being held back with CSS hacks or fallbacks. Pixels have been swapped for rems and ems where appropriate to make responsive typography and component sizing even easier. If you need IE8 support, keep using Bootstrap 3. Rewrote all our JavaScript plugins. Every plugin has been rewritten in ES6 to take advantage of the newest JavaScript enhancements. They also now come with UMD support, generic teardown methods, option type checking, and tons more. Improved auto-placement of tooltips and popovers thanks to the help of a tool called Tether. Improved documentation. We rewrote it all in Markdown and added a few handy plugins to streamline examples and code snippets to make working with our docs way easier. Improved search is also on it’s way. And tons more! Custom form controls, margin and padding classes, new utility classes, and more have also been included. And that barely scratches the surface of the 1,100 commits and 120,000 lines of changes in v4 so far. Plus, we’re not even done yet! Ready to check it out? http://v4-alpha.getbootstrap.com Development plan We need your help to make Bootstrap 4 the best it can be. Starting today, the source code for v4 will be available in a v4-dev branch on GitHub. In addition, we have a v4 development and tracking pull request that includes a master checklist of changes we’ve made and our remaining possible todos. We’d love for y’all to help chip away at those todos. The general development and release plan looks something like this: A few alpha releases while things are still in flux. Two beta releases after features and functionality are locked down to really test things out. Two release candidates (RCs) to really test things out closer to production environments. Then, the final release! For those jamming on v4 with us, we also have a dedicated v4 Slack channel. Jump in to talk shop and work with your fellow Bootstrappers. If you haven’t yet, join our official Slack room!. If you’re not keen on pushing code to v4, we’d love to hear from you in our issue tracker with bug reports, questions, and general feedback. Supporting v3 When we shipped Bootstrap 3, we immediately discontinued all support for v2.x, causing a lot of pain for all our users out there. That was a mistake we won’t be making again. For the foreseeable future, we’ll be maintaining Bootstrap 3 with critical bug fixes and documentation improvements. v3 docs will also continue to be hosted after v4’s final release. |
dont know where you can learn in Ikeja (Stay there too)...
